Re: wait4 causes segfault in i386 chroot
On 6/10/2004 7:02 PM, Ian Wienand wrote: A guess : the only major difference with the optimised libraries is they enable __thread which has the effect of putting errno in the TLS area (sysdeps/unix/sysv/linux/i386). TLS uses the %gs register to get at the thread local data. Now for some reason the gs register gets trashed somewhere along the way, say in a signal handler, it's possible that you'd get a segfault? Anyone got any other ideas (cc: [EMAIL PROTECTED] in case they do). Sounds like a variant of this problem: http://lia64.bkbits.net:8080/linux-ia64-2.5/[EMAIL PROTECTED]|src/|src/arch|src/arch/ia64|src/arch/ia64/ia32|related/arch/ia64/ia32/ia32_signal.c Is it possible for you to make a tarball for this particular glibc available ? It doesn't fail for me with # rpm -q glibc glibc-2.3.2-95.3 -Arun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wait4 causes segfault in i386 chroot
On Thu, Jun 10, 2004 at 12:08:26PM -0700, Arun Sharma wrote: On 6/9/2004 10:16 PM, Ian Wienand wrote: I've tracked it down to doing a wait/waitpid/wait4 (they all end up in wait4) in a sigchld signal handler. If I do a minimal test case where I catch the sigchld and wait, once the call returns it segfaults as in this trace (gdb can't seem to give a good backtrace). I recall seeing this problem earlier. But I'm unable to reproduce it now. I tried with 2.4.x and 2.6.6. Will try 2.6.7-rc3 later today. What was your glibc version ? Hi, I can replicate it with 2.6.6, so I guess we must have different libcs :( The libc is 2.3.2.ds1-13 from Debian unstable. With this in mind, I ran in the chroot with LD_LIBRARY_PATH=/usr/lib/debug and to my surprise things seemed to work. Run it again with LD_LIBRARY_PATH=/usr/lib/debug/lib/tls (or indeed just leave the default path) and it segfaults. A guess : the only major difference with the optimised libraries is they enable __thread which has the effect of putting errno in the TLS area (sysdeps/unix/sysv/linux/i386). TLS uses the %gs register to get at the thread local data. Now for some reason the gs register gets trashed somewhere along the way, say in a signal handler, it's possible that you'd get a segfault? Anyone got any other ideas (cc: [EMAIL PROTECTED] in case they do). -i signature.asc Description: Digital signature
Re: wait4 causes segfault in i386 chroot
On Thu, Jun 10, 2004 at 12:08:26PM -0700, Arun Sharma wrote: On 6/9/2004 10:16 PM, Ian Wienand wrote: I've tracked it down to doing a wait/waitpid/wait4 (they all end up in wait4) in a sigchld signal handler. If I do a minimal test case where I catch the sigchld and wait, once the call returns it segfaults as in this trace (gdb can't seem to give a good backtrace). I recall seeing this problem earlier. But I'm unable to reproduce it now. I tried with 2.4.x and 2.6.6. Will try 2.6.7-rc3 later today. What was your glibc version ? Hi, I can replicate it with 2.6.6, so I guess we must have different libcs :( The libc is 2.3.2.ds1-13 from Debian unstable. With this in mind, I ran in the chroot with LD_LIBRARY_PATH=/usr/lib/debug and to my surprise things seemed to work. Run it again with LD_LIBRARY_PATH=/usr/lib/debug/lib/tls (or indeed just leave the default path) and it segfaults. A guess : the only major difference with the optimised libraries is they enable __thread which has the effect of putting errno in the TLS area (sysdeps/unix/sysv/linux/i386). TLS uses the %gs register to get at the thread local data. Now for some reason the gs register gets trashed somewhere along the way, say in a signal handler, it's possible that you'd get a segfault? Anyone got any other ideas (cc: debian-glibc@lists.debian.org in case they do). -i signature.asc Description: Digital signature
