Hi,
Here are the stack traces:
=> LD_DEBUG=bindings
On Tue, Mar 15, 2016 at 10:30:07PM +0100, Samuel Thibault wrote:
> Hello,
>
> Diego Nieto Cid, on Sun 13 Mar 2016 18:28:46 -0300, wrote:
> > => 0x0001052b <_dl_start_profile+235>: mov %eax,-0x24c(%ebp)
> > 0x00010531 <_dl_start_profile+241>: lea -0x224(%ebp),%eax
(gdb) bt
#0 0x0001052b in _dl_start_profile () at dl-profile.c:242
#1 0x00010a59 in _dl_start_profile () at dl-profile.c:459
#2 0x0000f008 in _dl_fini () at dl-fini.c:156
#3 0x6d5f6863 in ?? ()
#4 0x5f006773 in ?? ()
#5 0x735f4f49 in ?? ()
#6 0x705f7274 in ?? ()
#7 0x6b636162 in ?? ()
#8 0x6c696166 in ?? ()
#9 0x73637700 in ?? ()
#10 0x6c756f74 in ?? ()
#11 0x736f7000 in ?? ()
#12 0x665f7869 in ?? ()
#13 0x69766461 in ?? ()
#14 0x34366573 in ?? ()
#15 0x665f5f00 in ?? ()
#16 0x74697277 in ?? ()
#17 0x656c6261 in ?? ()
#18 0x61736900 in ?? ()
#19 0x69696373 in ?? ()
#20 0x74757000 in ?? ()
#21 0x00766e65 in ?? ()
Backtrace stopped: Cannot access memory at address 0x616d5f63
----------------------------------
=> LD_DEBUG=statistics
> >
> > => 0x00017812 <__strerror_r+194>: pushl (%eax,%edi,4)
> > 0x00017815 <__strerror_r+197>: call 0x1aff0
> > <__mutex_lock_solid>
>
(gdb) bt
#0 0x00017812 in __strerror_r (errnum=16959932,
buf=0x1 <error: Cannot access memory at address 0x1>, buflen=74)
at dl-minimal.c:189
#1 0xffffffff in ?? ()
#2 0x0102c9bc in ?? ()
#3 0x00010643 in _dl_start_profile () at dl-profile.c:322
#4 0x00010a59 in _dl_start_profile () at dl-profile.c:459
#5 0x01092597 in ?? ()
#6 0x00000000 in ?? ()
---------------------------------
=> And using LD_DEBUG=symbols
Program received signal ?, Unknown signal.
0x0001b00a in __mutex_lock_solid (
lock=<error reading variable: Cannot access memory at address 0x2c7e8>) at
mutex-solid.c:31
31 }
(gdb) disassemble $eip,+8
Dump of assembler code from 0x1b00a to 0x1b012:
=> 0x0001b00a <__mutex_lock_solid+26>: movzwl 0x2a(%esp),%eax
0x0001b00f: mov 0x868(%esp),%esi
End of assembler dump.
(gdb) bt
#0 0x0001b00a in __mutex_lock_solid (
lock=<error reading variable: Cannot access memory at address 0x2c7e8>) at
mutex-solid.c:31
Backtrace stopped: Cannot access memory at address 0x2c7e4
--------------------------------
> In both cases it fails while trying to write to the stack. Does perhaps
> backtrace show a long recursion? Or perhaps the stack here is too small
> for what dl.so wants to do?
>
The stack being 'weird' is a common theme, indeed. Although,
I'm not sure how reliable the stacktraces are and the point
of failure may not even be relevant :(
Can gcc's stack smashing protector (-fstack-protector) be
used in glibc? Maybe, it will fail faster and closer to the
real problem.
Thanks,
Diego
