From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12365 invoked by alias); 9 Dec 2014 22:02:08 -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 12329 invoked by uid 48); 9 Dec 2014 22:02:03 -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 22:02: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: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-12/txt/msg00078.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17691 --- Comment #5 from Matthew Dahl --- (In reply to Ondrej Bilka from comment #4) > On Tue, Dec 09, 2014 at 08:45:05PM +0000, matthew.dahl at yahoo dot com > wrote: > > That is exactly what I was thinking (no memory access, so how a segfault > > happened?), any way we have calculated the offset set from our two different > > occurrences and both point to the same value (0xC356). > > The program is written in C and does nothing too special, main executes, it > > creates two pthreads and enters a "running" loop and that is about it, and > > 99.999....9% of time everything works as expected. > > > > Could you clarify what you mean by your last comment "I would look if there is > > robust lock in initializers before main is called?". > > > > Do you mean usage/instances of "pthread_mutex_t mutex = > > PTHREAD_MUTEX_INITIALIZER;"? If yes, there are none used. > > > I meant using mutex in C++ constructor or function in > __attribute__((constuctor)) > > If not I do not know how that could happen, only other memory access there > is dereferencing mutex pointer. Ok, well I'm still continuing to attempt to re-produce this issue (not expecting to see it happen, as I am the 3rd or 4th engineer to look at this; and we have yet to re-produce it). If I do get any more information I'll post here, will just consider this a memory corruption issue for now. Thanks for your time. -- You are receiving this mail because: You are on the CC list for the bug.