Closed Bug 1307350 Opened 9 years ago Closed 9 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | dom/media/test/test_reset_src.html | application timed out after 330 seconds with no output

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla52
Tracking Flags:
Tracking Status
firefox50 --- unaffected
firefox51 --- unaffected
firefox52 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: bwc)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 2 obsolete files)

Bug 1307350: Compensate for repeating timers that have not been appropriately cancelled.
58 bytes, text/x-review-board-request
froydnj
: review+
Details
[task 2016-10-04T00:21:16.499773Z] 00:21:16 INFO - 0 libxul.so!nsIEventTarget::Dispatch [nsIEventTarget.h:b26e668306fb : 37 + 0x6] [task 2016-10-04T00:21:16.500902Z] 00:21:16 INFO - rbx = 0x00007feecaefe6d0 r12 = 0x00007feeb2f44fa0 [task 2016-10-04T00:21:16.501964Z] 00:21:16 INFO - r13 = 0x00007feecaefe748 r14 = 0x0000000000000000 [task 2016-10-04T00:21:16.503040Z] 00:21:16 INFO - r15 = 0x00007feed77271f0 rip = 0x00007feee43208c5 [task 2016-10-04T00:21:16.504141Z] 00:21:16 INFO - rsp = 0x00007feecaefe6c0 rbp = 0x00007feecaefe710 [task 2016-10-04T00:21:16.505909Z] 00:21:16 INFO - Found by: given as instruction pointer in context [task 2016-10-04T00:21:16.507021Z] 00:21:16 INFO - 1 libxul.so!TimerThread::PostTimerEvent [TimerThread.cpp:b26e668306fb : 701 + 0xd] [task 2016-10-04T00:21:16.508084Z] 00:21:16 INFO - rbx = 0x00007feecaefe7d8 r12 = 0x00007feecaefe740 [task 2016-10-04T00:21:16.509153Z] 00:21:16 INFO - r13 = 0x00007feecaefe748 r14 = 0x00007feec89a6598 [task 2016-10-04T00:21:16.510222Z] 00:21:16 INFO - r15 = 0x00007feed77271f0 rip = 0x00007feee4348329 [task 2016-10-04T00:21:16.511285Z] 00:21:16 INFO - rsp = 0x00007feecaefe720 rbp = 0x00007feecaefe780 [task 2016-10-04T00:21:16.512326Z] 00:21:16 INFO - Found by: call frame info [task 2016-10-04T00:21:16.513399Z] 00:21:16 INFO - 2 libxul.so!TimerThread::Run [TimerThread.cpp:b26e668306fb : 473 + 0x4] [task 2016-10-04T00:21:16.514536Z] 00:21:16 INFO - rbx = 0x00007feed77271f0 r12 = 0x00007feecaefe7c8 [task 2016-10-04T00:21:16.515616Z] 00:21:16 INFO - r13 = 0x00007feecaefe7d8 r14 = 0x00007feecaefe7c0 [task 2016-10-04T00:21:16.516662Z] 00:21:16 INFO - r15 = 0x00007feecaefe7d0 rip = 0x00007feee4348658 [task 2016-10-04T00:21:16.517903Z] 00:21:16 INFO - rsp = 0x00007feecaefe790 rbp = 0x00007feecaefe810 [task 2016-10-04T00:21:16.519029Z] 00:21:16 INFO - Found by: call frame info [task 2016-10-04T00:21:16.520099Z] 00:21:16 INFO - 3 libxul.so!nsThread::ProcessNextEvent [nsThread.cpp:b26e668306fb : 1082 + 0x10] Might be related to recent changes to nsTimerImpl.
Component: Audio/Video → XPCOM
See Also: → 1157323
It probably is. I think we may be tripping over code that misuses the timer API. I have a patch I'd like to try. Hopefully this failure is somewhat reproducible...
Well, not seeing it in a bunch of retriggers, but not sure of the baseline rate to expect. Trying to figure that out.
Assignee: nobody → docfaraday
See Also: → 1309075
Attachment #8797638 - Attachment is obsolete: true
Comment on attachment 8802276 [details] Bug 1307350: Acquire a reference before unlocking, just in case. https://reviewboard.mozilla.org/r/86708/#review86006 This doesn't strike me as correct: AFAICT, the crash at the beginning of this bug is due to `target` being `nullptr`, which this patch wouldn't do anything for. I could see this patch helping for something like bug 1309075, but I'm not sure that it's the best way to solve the problem there. (I think JW pointed out that we're touching `mEventTarget` without proper locking, so if that's the case, we should fix that instead.)
Attachment #8802276 - Flags: review?(nfroyd)
Comment on attachment 8802276 [details] Bug 1307350: Acquire a reference before unlocking, just in case. https://reviewboard.mozilla.org/r/86708/#review86006 We only touch mEventTarget if the timer is currently disabled (ie; the TimerThread doesn't have a reference). The current code grabs a bare pointer and then unlocks the TimerThread's mutex, which opens the opportunity for code on the target thread to Cancel the timer, unset (or re-set) mEventTarget, possibly destroying the thing that bare pointer is pointing at.
Comment on attachment 8802276 [details] Bug 1307350: Acquire a reference before unlocking, just in case. https://reviewboard.mozilla.org/r/86708/#review86006 OK, thanks for the explanation. That scenario is plausible for something like bug 1309075, and some of the crashes in crash-stats, but it doesn't explain the crash in this bug, because we grabbed `nullptr` under the mutex. (For future patches, it would be helpful if you would provide that sort of explanation with the patch, so we don't have to do this back-and-forth.)
Crud, I think I put this patch on the wrong bug. Let me straighten this out.
Attachment #8802276 - Attachment is obsolete: true
Comment on attachment 8802705 [details] Bug 1307350: Compensate for repeating timers that have not been appropriately cancelled. https://reviewboard.mozilla.org/r/87024/#review86374
Attachment #8802705 - Flags: review?(nfroyd) → review+
Pushed by bcampen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6d552b35b479 Compensate for repeating timers that have not been appropriately cancelled. r=froydnj
https://hg.mozilla.org/mozilla-central/rev/6d552b35b479
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: