Data race on nsAppShell::mLastNativeEventScheduled

RESOLVED FIXED in mozilla27

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bent.mozilla, Assigned: roc)

Tracking

unspecified
mozilla27
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Many threads write this value, here's the main thread:

  xul.dll!ScheduleNativeEventCallback - nsappshell.cpp:167
  xul.dll!ProcessNextNativeEvent - nsappshell.cpp:243
  xul.dll!DoProcessNextNativeEvent - nsbaseappshell.cpp:139
  xul.dll!OnProcessNextEvent - nsbaseappshell.cpp:286
  xul.dll!ProcessNextEvent - nsthread.cpp:595
  xul.dll!NS_ProcessNextEvent - nsthreadutils.cpp:238
  xul.dll!Run - messagepump.cpp:81

And here's the timer thread (though any thread that calls Dispatch on the main thread will end up here I think):

  xul.dll!ScheduleNativeEventCallback - nsappshell.cpp:167
  xul.dll!OnDispatchedEvent - nsbaseappshell.cpp:235
  xul.dll!PutEvent - nsthread.cpp:362
  xul.dll!Dispatch - nsthread.cpp:404
  xul.dll!PostTimerEvent - nstimerimpl.cpp:670
  xul.dll!Run - timerthread.cpp:232

TimeStamp is > 128 bits on windows so there's no way this assignment is atomic. If we read at a bad time here http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsAppShell.cpp#241 then I'm not sure if we're going to mess up our reference count somehow.
Created attachment 795270 [details] [diff] [review]
fix

I don't think this matters all that much. The check in ProcessNextNativeEvent is really only a heuristic.
Assignee: nobody → roc
Attachment #795270 - Flags: review?(benjamin)

Updated

5 years ago
Attachment #795270 - Flags: review?(benjamin) → review+
https://hg.mozilla.org/mozilla-central/rev/1f52d046c2e7
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.