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)
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
Comment 1•12 years ago
|
||
(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() ]
status-firefox22:
--- → unaffected
status-firefox23:
--- → affected
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
Updated•12 years ago
|
Crash Signature: [@ mozilla::dom::AudioContext::UpdatePannerSource() ] → [@ mozilla::dom::AudioContext::UpdatePannerSource()]
Assignee | ||
Comment 4•12 years ago
|
||
Actually, I can't repro on Linux and my Windows build needed a clobber, I'm going to look a that tomorrow.
Assignee | ||
Comment 5•12 years ago
|
||
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)
Reporter | ||
Comment 6•12 years ago
|
||
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.
Comment 7•12 years ago
|
||
(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)
Assignee | ||
Comment 8•12 years ago
|
||
Ah, I could successfully reproduce on a Nightly, but not on a debug build, thanks.
Updated•12 years ago
|
Crash Signature: [@ mozilla::dom::AudioContext::UpdatePannerSource()] → [@ mozilla::dom::AudioContext::UpdatePannerSource()]
[@ mozilla::dom::PannerNode::FindConnectedSources()]
OS: Windows 7 → All
Hardware: x86 → All
Updated•12 years ago
|
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:…
Updated•12 years ago
|
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*> >&)]
Updated•12 years ago
|
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() ]
Comment 9•12 years ago
|
||
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?
Comment 10•12 years ago
|
||
(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
Comment 11•12 years ago
|
||
(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! :-)
Comment 12•11 years ago
|
||
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.
Description
•