zsh-workers
 help / color / mirror / code / Atom feed
From: Charles Daffern <seejay.11@gmail.com>
To: zsh-workers@zsh.org
Subject: zsh 5.2 build with --enable-stack-allocation crashes on large environments
Date: Tue, 18 Oct 2016 13:27:09 +0100	[thread overview]
Message-ID: <5aa037f1-d019-8186-89f6-16a5a48d550a@gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]

Hi,


When building a copy of zsh 5.2 for personal use, I stumbled upon this
rather unusual bug.

You can reproduce it with something like this sequence of commands in
the zsh 5.2 source directory:


./configure --enable-stack-allocation

make

x=xxxxxxxx

for i ({1..6}) x=$x$x$x$x

export x

Src/zsh -f


The large environment variable causes zsh to crash on launch. Equally, a
large number of environment variables has the same effect.

Debugging shows this:


 1. Program received signal SIGSEGV, Segmentation fault.
 2. 0x000000000045cdbf in popheap () at mem.c:512
 3. 512 hl->next = NULL;
 4. (gdb) bt
 5. #0 0x000000000045cdbf in popheap () at mem.c:512
 6. #1 0x00000000004706f2 in createparamtable () at params.c:772
 7. #2 0x00000000004495ef in setupvals () at init.c:1045
 8. #3 0x0000000000449c9b in zsh_main (argc=<value optimized out>,
    argv=<value optimized out>) at init.c:1659
 9. #4 0x000003fff71d1d1d in __libc_start_main (main=0x40f3a0 <main>,
    argc=1, ubp_av=0x3ffffff8368, init=<value optimized out>,
    fini=<value optimized out>,
10. rtld_fini=<value optimized out>, stack_end=0x3ffffff8358) at
    libc-start.c:226
11. #5 0x000000000040f2d9 in _start ()


It's having trouble dereferencing "hl", and it turns out there's a
reason for that:


 1. Breakpoint 1, popheap () at mem.c:502
 2. (gdb) print h
 3. $1 = (struct heap *) 0x3fff7fec000
 4. (gdb) print heaps
 5. $2 = (Heap) 0x3fff7fe8000
 6. (gdb) c
 7. Continuing.
 8.
 9. Breakpoint 1, popheap () at mem.c:502
10. (gdb) print h
11. $3 = (struct heap *) 0x3fff7fe8000
12. (gdb) print heaps
13. $4 = (Heap) 0x3fff7fe8000


The above breakpoint is on the munmap in popheap. The entire "heaps"
variable is being freed at one point (because "h" is freed and they
became equal for some reason). I'm not familiar enough with the code to
figure out how this is happening though.


The bug is triggered by the --enable-stack-allocation option to
configure. Without that option, zsh works as expected.

Apologies in advance for the formatting, Thunderbird still thinks it's
in WYSIWYG mode and I'm not entirely sure how this email will end up
when it churns out the plain-text form.


Thanks,

Charles Daffern



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

             reply	other threads:[~2016-10-18 21:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-18 12:27 Charles Daffern [this message]
2016-10-18 23:46 ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5aa037f1-d019-8186-89f6-16a5a48d550a@gmail.com \
    --to=seejay.11@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).