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 #4 from Ondrej Bilka <neleai at seznam dot cz> ---
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.

-- 
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]