Closed Bug 1133024 Opened 9 years ago Closed 3 years ago

TSan: data race dom/media/webrtc/MediaEngineDefault.cpp:251 NotifyPull

Categories

(Core :: WebRTC: Audio/Video, defect, P5)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: froydnj, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tsan])

Attachments

(1 file)

Attached file media-race.txt
[cribbing from decoder's script, hopefully he won't mind]

The attached logfile shows a thread/data race 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 unacceptable 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.

Looks like MediaEngineDefaultVideoSource::mState isn't being appropriately protected by mMonitor, comments in MediaEngineDefault.h to the contrary.

[1] http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
Summary: TSan: data race → TSan: data race dom/media/webrtc/MediaEngineDefault.cpp:251 NotifyPull
Component: Video/Audio → WebRTC: Audio/Video
backlog: --- → webRTC+
Rank: 45
Priority: -- → P4
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5

Looks like as of bug 1299515 this was fixed (no accesses into mState off of its owning thread).

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: