Closed Bug 1148397 Opened 6 years ago Closed 6 years ago

TSan: data race image/src/imgRequest.h:119 HadInsecureRedirect


(Core :: ImageLib, defect)

Not set



Tracking Status
firefox39 --- fixed


(Reporter: froydnj, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [tsan] gfx-noted)


(2 files)

The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer).

* Specific information about this bug

I'm not entirely clear on the race here, but Seth asked me to file this one.  The reading side is pretty obvious, in imgRequest::HadInsecureRace.  One interesting thing about this race is that the member in question, mHadInsecureRedirect, is a bitfield, so the "write" to the field doesn't necessarily have to be that member; it could be any of the members that share the same byte of storage in the imgRequest object.

That being said, the stack for the writing side of the race is not terribly helpful.  It is particularly odd to me that nsRefPtr::operator= is being fingered, as that should be copying pointers only, and not twiddling the bits of imgRequest objects itself.  I'm going to chalk that one up to bad debug information and/or bad propagation of debug information during inlining.

Still doesn't help pinpoint the location of the write, though.  I looked at all the places where mHadInsecureRedirect was written and--though I didn't trace call chains or anything like that--none of them looked like they would be called from OnDataAvailable.  I didn't perform exhaustive analysis of all the fields sharing byte storage with mHadInsecureRedirect, either.

All that is long-winded analysis for something that Seth made it sound like was added fairly recently, so perhaps he'll have a much better idea of where to look. :)  ni? Seth just to ensure this gets into his queue.

* 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.

[2] _How to miscompile programs with "benign" data races_:
Flags: needinfo?(seth)
Bugs are much more helpful when they have descriptive titles.
Summary: TSan: data race → TSan: data race image/src/imgRequest.h:119 HadInsecureRedirect
Whiteboard: [tsan] → [tsan] gfx-noted
This got introduced in bug 1082837, which just landed, and contained a patch that dated from before the recent TSan fixes in ImageLib. That patch broke the invariant that we need to take the imgRequest's lock when accessing the bitfield.

Unlike the previous issues, fixing this won't require a big rewrite or anything, so I'll just do it in this bug.
Here's the patch. We just need to take the lock when accessing
Flags: needinfo?(seth)
Attachment #8584937 - Flags: review?(tanvi)
Comment on attachment 8584937 [details] [diff] [review]
Fix data race on imgRequest::mHadInsecureRedirect.

This looks okay to me, but I'm probably no the best reviewer for this.
Attachment #8584937 - Flags: review?(tanvi) → feedback+
Attachment #8584937 - Flags: review?(tnikkel)
Attachment #8584937 - Flags: review?(tnikkel) → review+
Thanks for the review!
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.