[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#383976: unable to upgrade package libc6



On Tue, Aug 22, 2006 at 07:00:31PM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 22, 2006 at 03:56:13PM +0200, Aurelien Jarno wrote:
> > I now have a more precise idea of the problem. The following command
> > produce a segfault:
> > 
> > LD_ASSUME_KERNEL=2.4.1 LD_PRELOAD=/usr/lib/libaoss.so /bin/bash -x /bin/egrep
> > 
> > where /bin/grep contains:
> > 
> > #!/bin/sh
> > exec grep -E ${1+"$@"}
> > 
> > Note that without LD_ASSUME_KERNEL=2.4.1 (ie using nptl instead of
> > linuxthreads) or using dash instead of bash, the problem goes out.
> > 
> > gdb returns nothing, so I don't really know where is the problem and how
> > to debug it.
> 
> Can you get a core dump?  Alternatively, inserting gdbserver before
> /bin/bash and using remote debugging sometimes helps; it perturbs the
> process less than gdb does.  But only if the parent process is the one
> you need to debug.
> 

Well I have found the problem since then:

20:35 < aurel32> I have found the problem of bug#383976, but I will need some help to take a decision.
20:35 < aurel32> first the bug has been triggered by local-sysctl.diff (the patch that removes call sysctl())
20:36 < aurel32> but even without this patch, it will be triggered by a switch to a 2.6.18 kernel
20:36 < aurel32> where the sysctl() function will always fail
20:36 < aurel32> then the problem:
20:37 < aurel32> preloading libaoss.so diverts some symbols such as open, __open, read, __read, etc.
20:37 < aurel32> libaoss.so is linked with libpthread.so
20:37 -!- xaiki [~xaiki@cxhome.ath.cx] has joined #debian-glibc
20:37 < aurel32> libpthread run a few checks at initialization, like checking if the kernel is an SMP one or not
20:37 < aurel32> before it was using sysctl() and then __open("/proc/sys/kernel/version", O_RDONLY)
20:37 < aurel32> but now it directly uses __open()
20:38 < aurel32> so when loading libpthread.so, the __open() function from libaoss.so is started
20:38 < aurel32> it calls getenv() to read variables from __environ
20:39 < aurel32> but at that time this variable is not yet initialized
20:39 < aurel32> causing a segfault
20:39 < aurel32> To fix the problem:
20:39 < aurel32> - I don't understand why __ functions are diverted in alsa-oss, maybe this is not necessary???
20:40 < aurel32> - The upstream version of smp.h now always assume an SMP kernel
20:40 < aurel32> this is actually the case with newer debian kernels, which are now SMP

I have finally decided to use the fix which is in upstream CVS.

BTW, it would be nice if you can sync smp.h from linuxthreads with the one from NPTL in upstream CVS.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net



Reply to: