Re: Bug#249627: Alias + LC_CTYPE + function => segmentation fault

Re: Bug#249627: Alias + LC_CTYPE + function => segmentation fault

[Clint Adams]

I can't reproduce this myself.  Does gdb tell you anything?

On Tue, May 18, 2004 at 05:22:57PM +0200, Nicolas George wrote:
> Package: zsh
> Version: 4.2.0-10
> 
> With no config file at all (/etc/zsh removed and HOME=/tmp/empty), I get
> that:
> 
> ssecem% alias frobnicate="LC_CTYPE=en_US.UTF-8"
> ssecem% alias date="frobnicate date"
> ssecem% function date { command date; echo done }
> ssecem% date
> Tue May 18 17:08:42 CEST 2004
> done
> ssecem% date
> zsh: segmentation fault  HOME=/tmp/empty zsh
> 
> (Yes, I do have a real-world case where the bug appears.)
> 
> If I try to type "setopt" before all that to see enabled options (which
> are interactive, monitor, shinstdin and zle), the second date succeeds,
> but a third one sends zsh in an infinite loop eating all CPU.
> 
> 
> Here are details about my configuration:
> 
> debconf		1.4.25
> passwd		1:4.0.3-28
> libc6		2.3.2.ds1-12
> libcap1		1:1.10-14
> libncurses5	5.4-3
> 
> /usr/bin/zsh:
>                 libcap.so.1 => /lib/libcap.so.1 (0x40025000)
>         libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x40029000)
>         libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0x4002d000)
>         libncurses.so.5 => /lib/libncurses.so.5 (0x40042000)
>         libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x40081000)
>         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x400a4000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> Linux ssecem 2.6.5 #2 Wed Apr 14 23:36:02 CEST 2004 i686 GNU/Linux

Re: Bug#249627: Alias + LC_CTYPE + function => segmentation fault

[Nicolas George]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Le decadi 30 floréal, an CCXII, Clint Adams a écrit :
> I can't reproduce this myself.  Does gdb tell you anything?

That's strange, I have the same symptoms on several Debian Sarge
installations, but not all situation I test. I have built
zsh_4.2.0.orig.tar.gz without the Debian patches, and the problem is
still there. Here is a backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x4011513c in mallopt () from /lib/tls/i686/cmov/libc.so.6
(gdb) where
#0  0x4011513c in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1  0x00000000 in ?? ()
#2  0x4039c174 in ?? ()
#3  0x00000005 in ?? ()
#4  0xbffff598 in ?? ()
#5  0x08087581 in newparamtable ()
Previous frame inner to this frame (corrupt stack?)

I can send (or rather upload on an anonymous FTP) you a core file, the
binary, or even the whole build tree, if you find it necessary.

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: Bug#249627: Alias + LC_CTYPE + function => segmentation fault

[Clint Adams]

> That's strange, I have the same symptoms on several Debian Sarge
> installations, but not all situation I test. I have built
> zsh_4.2.0.orig.tar.gz without the Debian patches, and the problem is
> still there. Here is a backtrace:

If you rebuild the deb with DEB_BUILD_OPTIONS="debug", you'll get some
more verbose output from gdb.

> Program received signal SIGSEGV, Segmentation fault.
> 0x4011513c in mallopt () from /lib/tls/i686/cmov/libc.so.6
> (gdb) where
> #0  0x4011513c in mallopt () from /lib/tls/i686/cmov/libc.so.6
> #1  0x00000000 in ?? ()
> #2  0x4039c174 in ?? ()
> #3  0x00000005 in ?? ()
> #4  0xbffff598 in ?? ()
> #5  0x08087581 in newparamtable ()

zsh doesn't call mallopt() directly; it's probably being called from
another libc function such as free().  Can you repeat the problem under
valgrind with appropriate options?  Does it reveal anything?

Re: Bug#249627: Alias + LC_CTYPE + function => segmentation fault

[Nicolas George]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

Le decadi 30 floréal, an CCXII, Clint Adams a écrit :
> If you rebuild the deb with DEB_BUILD_OPTIONS="debug", you'll get some
> more verbose output from gdb.

I built only with ./configure, but I confess I did not check that the
build options enabled debugging, as they usually do with ./configure. I
re-tried with --enable-zsh-debug --enable-zsh-mem-debug
--enable-zsh-hash-debug. Here is the new backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x4011513c in mallopt () from /lib/tls/i686/cmov/libc.so.6
(gdb) where
#0  0x4011513c in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1  0x080b3f30 in gettext2 (state=0x40aa6070) at text.c:343
Previous frame inner to this frame (corrupt stack?)

> zsh doesn't call mallopt() directly; it's probably being called from
> another libc function such as free().  Can you repeat the problem under
> valgrind with appropriate options?  Does it reveal anything?

I do not know valgrind, so I am not sure which are the appropriate
options, but a raw "HOME=/tmp/empty valgrind ./Src/zsh" gives sime
interesting details:

[snip a lot of initialization]
zsh: failed to load module: zsh/zle  <--- I did not make install
ssecem% alias frobnicate="LC_CTYPE=en_US.UTF-8"
ssecem% alias date="frobnicate date"
ssecem% function date { command date; echo done }
ssecem% date
==29387== Warning: invalid file descriptor -1 in syscall close()
==29387== Warning: invalid file descriptor -1 in syscall close()
Tue May 18 21:11:15 CEST 2004
done
ssecem% date
==29385== 
==29385== Invalid free() / delete / delete[]
==29385==    at 0x3C01F918: free (vg_replace_malloc.c:127)
==29385==    by 0x808DC1D: zsfree (mem.c:1399)
==29385==    by 0x809B2D1: delenv (params.c:3455)
==29385==    by 0x80698F3: save_params (exec.c:2523)
==29385==  Address 0x3C3C9B24 is 0 bytes inside a block of size 21 free'd
==29385==    at 0x3C01F918: free (vg_replace_malloc.c:127)
==29385==    by 0x808DC1D: zsfree (mem.c:1399)
==29385==    by 0x809B1A8: addenv (params.c:3402)
==29385==    by 0x8069C67: restore_params (exec.c:2594)
==29389== Warning: invalid file descriptor -1 in syscall close()
==29389== Warning: invalid file descriptor -1 in syscall close()
Tue May 18 21:11:17 CEST 2004
done

Again, I can make a core file available if you need it. I guess the
final core would be rather useless, since according to valgrind, the
memory is probably already corrupted at this point, but I can use gdb to
produce a core at the entrance of save_params.

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: Bug#249627: Alias + LC_CTYPE + function => segmentation fault

[Peter Stephenson]

Nicolas George wrote:
> I do not know valgrind, so I am not sure which are the appropriate
> options, but a raw "HOME=/tmp/empty valgrind ./Src/zsh" gives sime
> interesting details:
> ==29385== 
> ==29385== Invalid free() / delete / delete[]
> ==29385==    at 0x3C01F918: free (vg_replace_malloc.c:127)
> ==29385==    by 0x808DC1D: zsfree (mem.c:1399)
> ==29385==    by 0x809B2D1: delenv (params.c:3455)
> ==29385==    by 0x80698F3: save_params (exec.c:2523)
> ==29385==  Address 0x3C3C9B24 is 0 bytes inside a block of size 21 =
> free'd
> ==29385==    at 0x3C01F918: free (vg_replace_malloc.c:127)
> ==29385==    by 0x808DC1D: zsfree (mem.c:1399)
> ==29385==    by 0x809B1A8: addenv (params.c:3402)
> ==29385==    by 0x8069C67: restore_params (exec.c:2594)
> ==29389== Warning: invalid file descriptor -1 in syscall close()
> ==29389== Warning: invalid file descriptor -1 in syscall close()
> Tue May 18 21:11:17 CEST 2004
> done

I don't think this is the same problem, since the programme finishes
correctly.  It does indicate something funny in saving and restoring
environment variables.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Bug#249627: Alias + LC_CTYPE + function => segmentation fault

[Nicolas George]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

Le primidi 1er prairial, an CCXII, Peter Stephenson a écrit :
> I don't think this is the same problem, since the programme finishes
> correctly.  It does indicate something funny in saving and restoring
> environment variables.

If it is a memory corruption caused by an invalid free, it is likely
that valgrind would either prevent it, or change the exact place where
the corruption occurs, thus changing the time it results in a
segmentation fault. I have seen that just having used "setopt" earlyer
changed a segfault on the second try into an infinite loop in the third
try: this problem is very sensitive to initial conditions.

I have tried Electric Fence, here is a backtrace, just after the second
date:

ssecem% date

ElectricFence Aborting: free(403cdfe8): address not from malloc().

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 1075767072 (LWP 1967)]
0xffffe410 in __kernel_vsyscall ()
(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x400ce156 in kill () from /lib/tls/i686/cmov/libc.so.6
#2  0x4002719b in EF_Abort () from /usr/lib/libefence.so
#3  0x40026ac1 in free () from /usr/lib/libefence.so
#4  0x0808dc1e in zsfree (p=0x403cdfe8 "") at mem.c:1399
#5  0x0809b2d2 in delenv (x=0x403cdfe8 "") at params.c:3455
#6  0x080698f4 in save_params (state=0xbffff7c0, pc=0x406d915c, 
    restore_p=0xbffff568, remove_p=0xbffff56c) at exec.c:2523
#7  0x08069314 in execcmd (state=0xbffff7c0, input=0, output=0, how=18, 
    last1=2) at exec.c:2371
#8  0x08065e47 in execpline2 (state=0xbffff7c0, pcode=387, how=18, input=0, 
    output=0, last1=0) at exec.c:1276
#9  0x08065381 in execpline (state=0xbffff7c0, slcode=6146, how=18, last1=0)
    at exec.c:1066
#10 0x08064cce in execlist (state=0xbffff7c0, dont_change_job=0, exiting=0)
    at exec.c:872
#11 0x080649ee in execode (p=0x406d9128, dont_change_job=0, exiting=0)
    at exec.c:773
#12 0x0807b253 in loop (toplevel=1, justonce=0) at init.c:165
#13 0x0807d99f in zsh_main (argc=1, argv=0xbffff8f4) at init.c:1274
#14 0x080521e6 in main (argc=1, argv=0xbffff8f4) at main.c:37

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]