[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356

["neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

--- Comment #2 from Ondrej Bilka <neleai at seznam dot cz> ---
On Tue, Dec 09, 2014 at 05:35:28PM +0000, matthew.dahl at yahoo dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=17691
> 
> --- Comment #1 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
> (In reply to Matthew Dahl from comment #0)
> > I am a software engineer at an avionics company, we have a system in the
> > field that has on two occasions reported a segmentation fault during
> > startup. Since this system is in a flight configuration we do not have core
> > dumps enabled nor is any additional logging available.
> > 
> > The following line is from the syslog.all is all we have to go on currently:
> > 
> > Jan  6 08:15:36 <SYSTEM-NAME> kernel: <APP-NAME>[5220]: segfault at 0 ip
> > b7576356 sp bfad46f8 error 4 in libpthread-2.7.so[b756a000+15000]
> > 
> > 
> > From our analysis it appears to died at offset 0x356 (b756a000 - bfad46f8)
> > in libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait
> > function at instruction (intel asm syntax)
> > 
> > c356:	81 ca 00 00 00 80    	or     edx,0x80000000
> > 
> > We have been unable to re-produce this issue here in our lab and I have
> > exhausted all of my resources attempting to find a root cause.
> > 

That offset is incorrect, as it does not access memory it cannot cause
segfault.

Most probable cause (unless mutex was corrupted) is that mutex uses tls
to determine tid which was not initialized, which also is previous
instruction in source:

2:      test    %eax, %eax
        jne     4b

        movl    %gs:TID, %edx
        orl     $FUTEX_WAITERS, %edx
        LOCK
        cmpxchgl %edx, (%ebx)
        jnz     4b


I would look if there is robust lock in initializers before main is
called?

-- 
You are receiving this mail because:
You are on the CC list for the bug.