This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
- From: "matthew.dahl at yahoo dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 09 Dec 2014 22:02:02 +0000
- Subject: [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
- Auto-submitted: auto-generated
- References: <bug-17691-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17691
--- Comment #5 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
(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.