This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]