wait4 causes segfault in i386 chroot

wait4 causes segfault in i386 chroot

[Ian Wienand]

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

Hi,

We just upgraded a box from 2.4 -> 2.6.7-rc3 and now we are seeing a
strange wait problem in a 386 chroot environment.  The initial problem
was that I could chroot into the directory where the 386 install is
kept, but as soon as whatever I ran from the shell prompt completed
the shell got a segv.  This happened with both bash and csh, but not
when you directed bash to exec something directly with a -c flag.

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).

[pid  8192] exit_group(1)               = ?  <-- child exits
Process 8192 detached
<... nanosleep resumed> 0xbffffbe4)     = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], WNOHANG, NULL) = 8192
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

However, if you do the wait in the parent directly it works fine!

Anyone have any ideas?

-i

--- minimal test program ---
#include <stdio.h>
#include <wait.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/wait.h>

int pid;

void sigchld_handler (int signum)
{
	int pid, status;
	while (!(pid = wait4(WAIT_ANY, &status, WNOHANG, NULL))) {
		if (pid < 0) {
			perror ("waitpid");
			break;
		}
		if (pid == 0)
			break;
	}
}

int main(int argc, char *argv[]) {

  int pid, status;

  signal(SIGCHLD, sigchld_handler);
  
  if ((pid = fork()) == -1)
	  exit(1);
  
  //child
  else if (pid == 0) {  
	  sleep(2);
	  exit(1);
  }
  
  //parent
  else {
	  //remove the sigchld handler and 
          //replace this with wait/waitpid/wait4() 
	  //and everything is fine
	  sleep(10);
  }
  
return 0;

}

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

Re: wait4 causes segfault in i386 chroot

[Arun Sharma]

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 ?

	-Arun

Re: wait4 causes segfault in i386 chroot

[Ian Wienand]

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

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

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

Re: wait4 causes segfault in i386 chroot

[Arun Sharma]

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:
> debian-glibc@lists.debian.org in case they do).
> 

Sounds like a variant of this problem:

http://lia64.bkbits.net:8080/linux-ia64-2.5/cset@3f9717925gK7Yi_LUHPyFzsyLpHMsA?nav=index.html|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