Bug#226688: libc6: i386: __libc_fork assertion in 2.3.2.ds1-10

[Mark Sheppard <mark@ddf.net>]

Package: libc6
Version: 2.3.2.ds1-10
Severity: critical

I'm getting the same behaviour as the bug in report #218546.  All
commands that use fork() fail with:

  ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork: Assertion
  `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm
  volatile ("movb %%gs:%P2,%b0" : "=q" (__value) : "0" (0), "i"
  (((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value)
  == 4) asm volatile ("movl %%gs:%P1,%0" : "=r" (__value) : "i"
  (((size_t) &((struct pthread *)0)->tid))); else { if (sizeof
  (__value) != 8) abort (); asm volatile ("movl %%gs:%P1,%%eax\n\t"
  "movl %%gs:%P2,%%edx" : "=A" (__value) : "i" (((size_t) &((struct
  pthread *)0)->tid)), "i" (((size_t) &((struct pthread *)0)->tid) +
  4)); } __value; }) != ppid' failed.
  Segmentation fault

So I guess that bug isn't entirely fixed yet.  This happened when I
was upgrading libc6 from stable to testing on a client's remote
server.  It's rented from a hosting company and had Debian
pre-installed.  Looks like the hosting company installed a custom
kernel:

  Linux mail 2.4.18200310143 #1 Fri Oct 24 14:42:51 BST 2003 i686 unknown

In the shell which I ran apt-get from I could run commands after
upgrading, but whenever they fork()ed to run any child processes they
would die with the above error (e.g. trying to downgrade again with
apt or dpkg), as would any commands on a new connection.  I guess the
commands that the old shell forked were still using the old (deleted)
libc.  So this meant I could go back to the old libc manually by
avoiding forks (using wget, ar, gunzip, tar, mv, ldconfig).

Mark.