Zsh Mailing List Archive
Messages sorted by:
Colon-array variables can crash "sh" emulation
- X-seq: zsh-workers 40974
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Colon-array variables can crash "sh" emulation
- Date: Fri, 14 Apr 2017 19:31:04 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:to:subject:mime-version; bh=0w+P6LW1YjTQEpdsheQ7S4X8Rn1XXYwmi/51N29aTyI=; b=g1/HlUe1BDVqT/xFaKe8IOgUKYONS63HsB8MXar8CI8hwEkSF+q7lm2CAJSOII37Zf EcYEFi4znwFYPMpL7/RFIbUpiOgE29Sk5Ctbf6WiQ+oHG0TFO9W3E9YfxnSloNqStowd VVShkDvmdP+CidyKldtK9bHgW+GlUZyKTG3x8jT2GHwocc5TVReWvbE/AP/Tb9hT7Yp+ H9pfXy9W/pqOgEvm1cVvAemK2Pox6X9VbakqEd0A5urjIHxdIVsSBsDT0cOjn1vhEQjL 15pBDbsTmIWIuo9l2EM2jCJaLicRm0AdMySNEnHG6QfapxTyhsCqpDfDRhai1FPGdJFI wkuw==
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
On Apr 14, 7:39pm, Anthony Fletcher wrote:
} Playing further I provoked a segmentation fault! This dies:
} ARGV0=sh zsh -c 'typeset -U path PATH'
Well, well, well.
The special_params array in Src/params.c is divided into two sections,
parameters available in all emulations and those available only in zsh
Trouble is the parameters in the first group include numerous colon-array
scalars that are potentially tied to true-arrays from the second group.
This normally doesn't cause any issues, because the parameters in the
second group are initialized only in the appropriate emulation.
BUT -- the parameters in the first group will still try to read values
from the linked parameters in the second group if the attributes of the
first parameter are changed, as by "typeset -U". Again this is usually
not a problem because the linked parameters are still not set.
However, if the linked parameter has been declared scalar, bin_typeset
will attempt to manipulate it as an array, and wallabies go roaming the
outback, as one of PWS's comments puts it.
This will happen with any pair of variables: path/PATH, watch/WATCH, etc.
However, I'm not sure of the best way to approach fixing this. My first
thought was that the linkage should be broken during createparamtable(),
but that turns out to be rather ugly to do.
Here's what valgrind has to say:
==16106== Invalid read of size 1
==16106== at 0x808DCE8: hasher (hashtable.c:85)
==16106== by 0x808E0BF: gethashnode2 (hashtable.c:255)
==16106== by 0x80C115F: arrayuniq (params.c:4001)
==16106== by 0x80C123B: uniqarray (params.c:4031)
==16106== by 0x80646F7: typeset_single (builtin.c:2201)
==16106== by 0x806753A: bin_typeset (builtin.c:2893)
==16106== by 0x805F232: execbuiltin (builtin.c:481)
==16106== by 0x808066F: execcmd_exec (exec.c:3879)
==16106== by 0x807AFC3: execpline2 (exec.c:1872)
==16106== by 0x8079E36: execpline (exec.c:1602)
==16106== by 0x807945B: execlist (exec.c:1360)
==16106== by 0x8078C69: execode (exec.c:1141)
==16106== Address 0x6C616300 is not stack'd, malloc'd or (recently) free'd
Messages sorted by: