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 [EMAIL PROTECTED] 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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]