Closed
Bug 939805
Opened 11 years ago
Closed 4 years ago
TSan: data race glib/gvarianttypeinfo.c:745 g_variant_type_info_get
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: decoder, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [tsan])
Attachments
(1 file)
(deleted),
text/plain
|
Details |
The attached logfile shows a thread/data race (mozilla-central revision beddd6d4bcdf) detected by TSan (ThreadSanitizer).
Typically, races reported by TSan are not false positives, but it is possible that the race is benign. Even in this case though, we should try to come up with a fix unless this would cause inacceptable performance issues. Also note that seemingly benign races can possibly be harmful (also depending on the compiler and the architecture) [1].
If the bug cannot be fixed, then this bug should be used to either make a compile-time annotation for blacklisting or add an entry to the runtime blacklist.
[1] http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
Reporter | ||
Comment 1•11 years ago
|
||
This looks like the race is coming from glib, but I cannot tell if we're using it somehow wrong (e.g. calling the some glib methods fro multiple threads in an unsafe way).
Summary: TSan: data race /build/buildd/glib2.0-2.32.1/./glib/gvarianttypeinfo.c:745 g_variant_type_info_get → TSan: data race glib/gvarianttypeinfo.c:745 g_variant_type_info_get
Comment 2•11 years ago
|
||
Is there any way to get better stack straces?
The log file may be skipping frames where functions are inlined.
Debug info contains the necessary info to unwind inlined frames, and addr2line can interpret this, but even the return addresses don't look right.
#1 g_rec_mutex_impl_new /build/buildd/glib2.0-2.32.1/./glib/gthread-posix.c:272 (libglib-2.0.so.0+0x000000083151)
#2 XREMain::XRE_main(int, char**, nsXREAppData const*) /srv/repos/browser/mozilla-central/toolkit/xre/nsAppRunner.cpp:4029 (libxul.so+0x00000085c33a)
#3 slab_allocator_alloc_chunk /build/buildd/glib2.0-2.32.1/./glib/gslice.c:1300 (libglib-2.0.so.0+0x00000001a0c9)
#4 XREMain::XRE_main(int, char**, nsXREAppData const*) /srv/repos/browser/mozilla-central/toolkit/xre/nsAppRunner.cpp:4029 (libxul.so+0x00000085c33a)
#1 g_system_thread_new /build/buildd/glib2.0-2.32.1/./glib/gthread-posix.c:1116 (libglib-2.0.so.0+0x000000083a7e)
#2 XREMain::XRE_main(int, char**, nsXREAppData const*) /srv/repos/browser/mozilla-central/toolkit/xre/nsAppRunner.cpp:4029 (libxul.so+0x00000085c33a)
I can't imagine how these three different functions would all return to the same instruction pointer position.
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•10 years ago
|
Component: General → Widget: Gtk
QA Contact: general
Comment 3•4 years ago
|
||
This bug has a weird stack trace and given its age I couldn't attribute it to any specific issue. I'm going to resolve this as a wontfix
since there isn't really anything actionable we could do here anymore.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•