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: "neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 09 Dec 2014 21:51:19 +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 #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.