ZSH-Bug (?): glibc, "double-free or corruption"

ZSH-Bug (?): glibc, "double-free or corruption"

[Jonas Kramer]

Hi,

I think I found a bug here. I'm just writing a CGI page in ZSH script 
and the server (lighttpd 1.4.7) kills my script and logs messages like 
the followings to the error log file:

(\M-x^M^HH($\M-3init.z:13: no matches found: ()
*** glibc detected *** double free or corruption (!prev): 0x080df4f8 ***
2005-12-27 00:16:55: (mod_cgi.c.553) cgi died, pid: 10981
\M-T^M^HHx\M-/\M-%init.z:13: no matches found: ()
*** glibc detected *** double free or corruption (!prev): 0x080dd168 ***
2005-12-27 00:21:25: (mod_cgi.c.553) cgi died, pid: 30457
\M-(*^N^HH\M-(\M-C\M-/init.z:13: no matches found: ()
*** glibc detected *** double free or corruption (!prev): 0x080e8478 ***
2005-12-27 00:23:16: (mod_cgi.c.553) cgi died, pid: 10287
\M-b^M^HHX5\M-"init.z:13: no matches found: ()
*** glibc detected *** double free or corruption (!prev): 0x080ddf68 ***
2005-12-27 00:23:44: (mod_cgi.c.553) cgi died, pid: 21509
\M-h]^N^HHx\M--\M-)init.z:13: no matches found: ()
*** glibc detected *** double free or corruption (!prev): 0x080e5ab8 ***
2005-12-27 00:25:17: (mod_cgi.c.553) cgi died, pid: 19649
x\M-4^M^HH\M-8\M-B\M-)init.z:13: no matches found: ()
*** glibc detected *** double free or corruption (!prev): 0x080db148 ***
2005-12-27 00:25:24: (mod_cgi.c.553) cgi died, pid: 27245
(\M-[^M^HHXQ\M-&init.z:13: no matches found: ()
*** glibc detected *** double free or corruption (!prev): 0x080dd7f8 ***
2005-12-27 00:26:13: (mod_cgi.c.553) cgi died, pid: 30891

The relevant source in init.z is the following:

typeset -A POST
if [ $CONTENT_LENGTH -gt 0 ]; then
  read -n 0 -k $CONTENT_LENGTH BUF
  IFS="\r\n"
  for LINE in ($(print $BUF)); do
    IFS="="
    X=($(print $LINE))
                print "$X[1] -> $X[2]<br>"
  done
fi

I'd be grateful for any ideas to avoid this behaviour until the bug is 
fixed. :)

Greetings,

Jonas

Re: ZSH-Bug (?): glibc, "double-free or corruption"

[Peter Stephenson]

Jonas Kramer <jonas.kramer@gmx.net> wrote:
> Hi,
> 
> I think I found a bug here. I'm just writing a CGI page in ZSH script 
> and the server (lighttpd 1.4.7) kills my script and logs messages like 
> the followings to the error log file:

> The relevant source in init.z is the following:
> 
> typeset -A POST
> if [ $CONTENT_LENGTH -gt 0 ]; then
>   read -n 0 -k $CONTENT_LENGTH BUF

As you pointed out, the -n should be -u.  I think the -n itself is simply
ignored if -c wasn't present.

The interpretation of the code as it stands is that all the arguments
from 0 onward are treated as parameter names, i.e. 0 -k $CONTENT_LENGTH
BUF.

Assigning to 0 is allowed; this changes $0, the script or function name.

If there are at least 2 fields, it will try to assign to -k.  This should
produce an error message.

$CONTENT_LENGTH is the interesting one.  It will try to assign the field to
the $CONTENT_LENGTH'th positional parameter.  If this is a large number,
you can get a huge positional array; but given this is supposed to be a
maximum byte size for the read builtin it doesn't actually look like that
will be a problem.  If you later do something with $* or $@ or loop using
$# you might have problems.

BUF will be unproblematic.

So I'm not really sure where your error messages were coming from.

>   IFS="\r\n"
>   for LINE in ($(print $BUF)); do

There's an idiom for this in zsh, it's so common:

   for LINE in ${(f)BUF}; do

This just handles newlines, so you may end up needing to strip carriage
returns:

  for LINE in ${${(f)BUF}%%$'\r'}; do

You shouldn't need the outer parentheses in any case.

>     IFS="="
>     X=($(print $LINE))

Again, you can split into words without using IFS or an extra process:

    X=(${(s.=.)LINE})

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


Your mail client is unable to display the latest news from CSR. To access our news copy this link into a web browser:  http://www.csr.com/email_sig.html