bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

TSan: data race js/src/../../js/src/jit/JitCompartment.h:240 setFlusher

RESOLVED FIXED in mozilla30

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: decoder, Assigned: shu)

Tracking

(Blocks: 1 bug)

Trunk
mozilla30
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tsan])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 8370442 [details]
Logfile with TSan trace

The attached logfile shows a thread/data race (mozilla-central revision 44ba69cacd7e) 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
This looks like a PJS race.
Flags: needinfo?(shu)
(Assignee)

Comment 2

5 years ago
Created attachment 8371997 [details] [diff] [review]
Move AutoFlushCache instances in parallel ICs under lock.
Attachment #8371997 - Flags: review?(efaustbmo)
(Assignee)

Updated

5 years ago
Assignee: general → shu
Status: NEW → ASSIGNED
(Assignee)

Updated

5 years ago
Flags: needinfo?(shu)

Comment 3

5 years ago
Comment on attachment 8371997 [details] [diff] [review]
Move AutoFlushCache instances in parallel ICs under lock.

Review of attachment 8371997 [details] [diff] [review]:
-----------------------------------------------------------------

OK, so the changes made by this patch are fine, r=me, but I'm desperately curious why each of those locked sections has an |if (cache.canAttachStub())| after a previous |if (!cache.canAttachStub() return true;|. That seems a little strange.
Attachment #8371997 - Flags: review?(efaustbmo) → review+
(Assignee)

Comment 4

5 years ago
(In reply to Eric Faust [:efaust] from comment #3)
> Comment on attachment 8371997 [details] [diff] [review]
> Move AutoFlushCache instances in parallel ICs under lock.
> 
> Review of attachment 8371997 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> OK, so the changes made by this patch are fine, r=me, but I'm desperately
> curious why each of those locked sections has an |if
> (cache.canAttachStub())| after a previous |if (!cache.canAttachStub() return
> true;|. That seems a little strange.

Because this is multithreaded code. :)

Before entering the critical (locked) section, we know that the cache can attach a stub, but another thread might have attached stubs in the meantime. We can have an interleaving like:

       T1                          |           T2
-----------------------------------+-------------------------------
 cache.canAttachStub() == true     |  cache.canAttachStub() == true
 acquires lock                     |
 attaches stub                     |
 releases lock                     |
                                   |  acquires lock
                                   |  cache.canAttachStub() == false
https://hg.mozilla.org/mozilla-central/rev/479ce9c26b7e
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.