bug-hurd
[Top][All Lists]
Advanced

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

Re: LD_DEBUG crashes applications


From: Diego Nieto Cid
Subject: Re: LD_DEBUG crashes applications
Date: Wed, 16 Mar 2016 00:11:39 -0300
User-agent: Mutt/1.5.24 (2015-08-30)

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 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]