From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24004 invoked by alias); 9 Dec 2014 17:35:33 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 23931 invoked by uid 48); 9 Dec 2014 17:35:28 -0000 From: "matthew.dahl at yahoo dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356 Date: Tue, 09 Dec 2014 17:35:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: matthew.dahl at yahoo dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-12/txt/msg00069.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D17691 --- Comment #1 from Matthew Dahl --- (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 co= re > dumps enabled nor is any additional logging available. >=20 > The following line is from the syslog.all is all we have to go on current= ly: >=20 > Jan 6 08:15:36 kernel: [5220]: segfault at 0 ip > b7576356 sp bfad46f8 error 4 in libpthread-2.7.so[b756a000+15000] >=20 >=20 > 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) >=20 > c356: 81 ca 00 00 00 80 or edx,0x80000000 >=20 > 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. >=20 >=20 > System Info: > Intel(R) Core(TM)2 CPU L7400 > Running Debian Kernel Version 2.6.32.8 Correction: >>From our analysis it appears to died at offset 0x356 (b7576356 - b756a000)= in libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait function at instruction (intel asm syntax) --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-26827-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Dec 09 19:26:08 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 25469 invoked by alias); 9 Dec 2014 19:26:07 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 25451 invoked by uid 89); 9 Dec 2014 19:26:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: popelka.ms.mff.cuni.cz Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Dec 2014 19:26:03 +0000 Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id 70947445CB; Tue, 9 Dec 2014 20:25:58 +0100 (CET) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id 2ED675F7E4; Tue, 9 Dec 2014 20:25:58 +0100 (CET) Date: Tue, 09 Dec 2014 19:26:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: "matthew.dahl at yahoo dot com" Cc: glibc-bugs@sourceware.org Subject: Re: [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356 Message-ID: <20141209192557.GA4641@domone> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00070.txt.bz2 Content-length: 1709 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 --- > (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 kernel: [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?