Closed Bug 863923 Opened 12 years ago Closed 12 years ago

Multiple access violation crashes in mozilla::dom::AudioContext::UpdatePannerSource after starting Rytlock's Critter Rampage

Categories

(Core :: Web Audio, defect)

23 Branch
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox22 --- unaffected
firefox23 --- affected

People

(Reporter: lh.bennett, Assigned: padenot)

References

()

Details

(Keywords: crash, regression, reproducible)

Crash Data

Nightly crashes shortly after starting a web game called Rytlock's Critter Rampage created by ArenaNET. Attached the URL. AFAIK, uses Canvas and Local Storage. BIDs: https://crash-stats.mozilla.com/report/index/bp-6eab1572-8b5a-4287-933c-922582130419 https://crash-stats.mozilla.com/report/index/bp-caa7719e-dcc2-4fc8-ae09-215322130419
(In reply to Leman Bennett (Omega X) from comment #0) > https://crash-stats.mozilla.com/report/index/bp-caa7719e-dcc2-4fc8-ae09- > 215322130419 It's bug 862705. > https://crash-stats.mozilla.com/report/index/bp-6eab1572-8b5a-4287-933c- > 922582130419 It's an audio crash: Frame Module Signature Source 0 xul.dll mozilla::dom::AudioContext::UpdatePannerSource content/media/webaudio/AudioContext.cpp:207 1 xul.dll mozilla::dom::AudioNode::Connect content/media/webaudio/AudioNode.cpp:141 2 xul.dll mozilla::dom::AudioNodeBinding::connect obj-firefox/dom/bindings/AudioNodeBinding.cpp:66 3 xul.dll mozilla::dom::AudioNodeBinding::genericMethod obj-firefox/dom/bindings/AudioNodeBinding.cpp:207 I am able to reproduce it. Based on the stack trace and its first appearance (23.0a1/20130413), it's likely a regression from bug 853551. More reports at: https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Adom%3A%3AAudioContext%3A%3AUpdatePannerSource%28%29
Blocks: 853551
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ mozilla::dom::AudioContext::UpdatePannerSource() ]
Component: Canvas: 2D → Video/Audio
Ever confirmed: true
OS: Windows 8 → Windows 7
Hardware: x86_64 → x86
Summary: Multiple access violation crashes after starting Rytlock's Critter Rampage → Multiple access violation crashes in mozilla::dom::AudioContext::UpdatePannerSource after starting Rytlock's Critter Rampage
Version: Trunk → 23 Branch
Crash Signature: [@ mozilla::dom::AudioContext::UpdatePannerSource() ] → [@ mozilla::dom::AudioContext::UpdatePannerSource()]
Paul, can you please take a look?
Assignee: nobody → paul
Blocks: webaudio
Sure, will have a look today.
Status: NEW → ASSIGNED
Actually, I can't repro on Linux and my Windows build needed a clobber, I'm going to look a that tomorrow.
And I can't repro on Windows. Any clearer STR? Did you repro with a debug build, a regular nightly? What action did you perform in the game to make it crash?
Flags: needinfo?(scoobidiver)
This is all in regular Nightly. I visited the game page and started it up. After about 30 seconds of playing, a crash happened. I performed the same steps over and over, and each time it was the same crash every time. https://crash-stats.mozilla.com/report/index/bp-907c139f-02b2-44da-81c1-dd8552130423 https://crash-stats.mozilla.com/report/index/bp-4550ada9-41c2-4f5c-b509-7b2692130423 Try dying a couple of times. After the second death is usually when it crashes.
(In reply to Leman Bennett (Omega X) from comment #6) > After about 30 seconds of playing, a crash happened. Same for me.
Flags: needinfo?(scoobidiver)
Ah, I could successfully reproduce on a Nightly, but not on a debug build, thanks.
Crash Signature: [@ mozilla::dom::AudioContext::UpdatePannerSource()] → [@ mozilla::dom::AudioContext::UpdatePannerSource()] [@ mozilla::dom::PannerNode::FindConnectedSources()]
OS: Windows 7 → All
Hardware: x86 → All
Crash Signature: [@ mozilla::dom::AudioContext::UpdatePannerSource()] [@ mozilla::dom::PannerNode::FindConnectedSources()] → [@ mozilla::dom::AudioContext::UpdatePannerSource()] [@ mozilla::dom::PannerNode::FindConnectedSources()] [@ mozilla::dom::PannerNode::FindConnectedSources(mozilla::dom::AudioNode*, nsTArray<mozilla::dom::AudioBufferSourceNode*>&, std::set<mozilla::dom:…
Crash Signature: , std::set<mozilla::dom::AudioNode*, std::less<mozilla::dom::AudioNode*>, std::allocator<mozilla::dom::AudioNode*> >&) ] → , std::set<mozilla::dom::AudioNode*, std::less<mozilla::dom::AudioNode*>, std::allocator<mozilla::dom::AudioNode*> >&)]
Crash Signature: , std::set<mozilla::dom::AudioNode*, std::less<mozilla::dom::AudioNode*>, std::allocator<mozilla::dom::AudioNode*> >&)] → , std::set<mozilla::dom::AudioNode*, std::less<mozilla::dom::AudioNode*>, std::allocator<mozilla::dom::AudioNode*> >&)] [@ nsTArray_Impl<nsCookie*, nsTArrayInfallibleAllocator>::Clear() ]
Hmm, wait. Could this be a dupe of bug 865550? I just noted that bug 866141 seems pretty similar to this crash too, and they can both be explained by bug 865550. Have we had more of these crashes since bug 865550 has been fixed?
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #9) > Have we had more of these crashes since bug 865550 has been fixed? I can't reproduce it. In addition, there have been no crashes since 23.0a1/20130426. Bug 865550 was fixed in 23.0a1/20130427 so it has been fixed by another patch that landed one build earlier. I will file another bug for signatures I wrongly associated to this bug.
Status: ASSIGNED → RESOLVED
Crash Signature: [@ mozilla::dom::AudioContext::UpdatePannerSource()] [@ mozilla::dom::PannerNode::FindConnectedSources()] [@ mozilla::dom::PannerNode::FindConnectedSources(mozilla::dom::AudioNode*, nsTArray<mozilla::dom::AudioBufferSourceNode*>&, std::set<mozilla::dom:… → [@ mozilla::dom::AudioContext::UpdatePannerSource()]
Closed: 12 years ago
Resolution: --- → WORKSFORME
(In reply to comment #10) > (In reply to :Ehsan Akhgari (needinfo? me!) from comment #9) > > Have we had more of these crashes since bug 865550 has been fixed? > I can't reproduce it. In addition, there have been no crashes since > 23.0a1/20130426. Bug 865550 was fixed in 23.0a1/20130427 so it has been fixed > by another patch that landed one build earlier. > > I will file another bug for signatures I wrongly associated to this bug. Thanks so much! :-)
Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.
Component: Video/Audio → Web Audio
You need to log in before you can comment on or make changes to this bug.