Closed
Bug 1190976
Opened 9 years ago
Closed 4 years ago
TSan: data race js/src/gc/Tracer.cpp:69 DoCallback<Value>
Categories
(Core :: JavaScript: GC, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: froydnj, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [tsan])
Attachments
(1 file)
10.95 KB,
text/plain
|
Details |
The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer). * Specific information about this bug This race is uninteresting insofar as TSan only gave a one-sided stack for it. It would be super-interesting to know where the read is happening for this race; presumably it's happening in jitcode...or someplace else where TSan happened to be unlucky in figuring out what's going on. Terrence, is it possible to figure out what's going on from just this stack? I will keep my eyes open on further TSan runs for the other side. * General information about TSan, data races, etc. 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 unacceptable performance issues. Also note that seemingly benign races can possibly be harmful (also depending on the compiler and the architecture) [1][2]. 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 [2] _How to miscompile programs with "benign" data races_: https://www.usenix.org/legacy/events/hotpar11/tech/final_files/Boehm.pdf
Flags: needinfo?(terrence)
Comment 4•9 years ago
|
||
(In reply to Nathan Froyd [:froydnj][:nfroyd] from comment #0) > It would be super-interesting to know where the read is happening for > this race; presumably it's happening in jitcode...or someplace else where > TSan happened to be unlucky in figuring out what's going on. It's happening on a helper thread so it's probably another instance of updating pointers after compacting GC. It would be really useful to see the stack though.
Comment 5•9 years ago
|
||
(In reply to Jon Coppeard (:jonco) from comment #4) > (In reply to Nathan Froyd [:froydnj][:nfroyd] from comment #0) > > It would be super-interesting to know where the read is happening for > > this race; presumably it's happening in jitcode...or someplace else where > > TSan happened to be unlucky in figuring out what's going on. > > It's happening on a helper thread so it's probably another instance of > updating pointers after compacting GC. It would be really useful to see the > stack though. I don't see how this could race with JITed code. All non-compacting threads should be quiescent at this point. Nathan, could you keep an eye out for a stack for this?
Flags: needinfo?(nfroyd)
Reporter | ||
Comment 6•9 years ago
|
||
(In reply to Terrence Cole [:terrence] from comment #5) > I don't see how this could race with JITed code. All non-compacting threads > should be quiescent at this point. Nathan, could you keep an eye out for a > stack for this? You bet.
Flags: needinfo?(nfroyd)
Comment 7•4 years ago
|
||
I don't think there's enough information here to proceed. I'm going to close for now but please re-open if this is still happening and we can get a decent stack.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•