Bug#226688: libc6: i386: __libc_fork assertion in 2.3.2.ds1-10
On Thu, Jan 08, 2004 at 06:58:40AM +0000, Mark Sheppard wrote:
> On 2004-01-07 (Wednesday) at 22:39:18 -0500, Daniel Jacobowitz wrote:
> > On Wed, Jan 07, 2004 at 08:04:17PM +0000, Mark Sheppard wrote:
> > >
> > > 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
> [...]
> > > 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
> >
> [...]
> >
> > Um.... I really, really don't want to work around that. It's a
> > completely broken kernel version. What do you expect anything else
> > that checks the kernel version string to do?
>
> Fair enough if you need to parse the whole thing, but from what you've
> said it sounds like you don't have to:
>
> The code in ld.so is supposed to choose the copy of libc in /lib for
> any kernel version less than 2.6.0
>
> Maybe I'm missing something here, but couldn't you just check the
> major and minor version numbers and totally ignore the revision number
> (i.e. anything beyond the second ".")? Or if this is something that
> changed half way through the 2.5 kernels then you could only check the
> revision if major == 2 && minor == 5?
The code is not Debian specific. It lets you build glibc (or any other
library) for any specific kernel version and have it skipped for lower
versions. If someone builds a 2.4.22 library, how the heck am I
supposed to figure out if that's above or below 2.4.18200310143?
So I'm reluctant to do a hack/slash job on it to handle the specific
case we're using.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: