Closed Bug 416383 Opened 13 years ago Closed 13 years ago

Crash going back on and forth on www.strato.de [@nsDOMAttribute::GetValue(nsAString_internal&)]

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: cbook, Assigned: smaug)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

Attached file crash log
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008020717 Firefox/3.0b4pre

Steps to reproduce:

- Go to https://www.strato.de/ordering/?phase=Hosting&step=select_package&artikel_gruppe=PWEB&artikel=PWEB_PRO
- Click on "weiter"
- next page loads
- go back
crash

Reported by isv during the firfox 3 beta 3 testday. His crash reporter url for this crash on linux is http://crash-stats.mozilla.com/report/index/3f4e0dab-d55a-11dc-a0bc-001a4bd43e5c

Attached is also my crash report from my debug build. Crashs also Windows Fx 3 Beta3 Builds.
Flags: blocking-firefox3?
Component: General → DOM
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
The crash stack makes me suspect DOM or cycle collector.
Flags: blocking1.9?
Summary: Crash going back on and forth on www.strato.de → Crash going back on and forth on www.strato.de [@nsDOMAttribute::GetValue(nsAString_internal&)]
The crash also occurs when you close the tab or window with
the page in it.

I believe this is caused by a document in an iframe using
window.setInterval to make an AJAX request. I can't tell
if that request is still made before the crash. If the
request succeeds, the function tries to access the page's
DOM, which I suppose isn't there anymore. In any case,
the crash takes place in time with the setInterval timing.

The document from the iframe does not crash on its own. It's
https://strato-customercare.de/kundenchat/frontend/logon.php?artikelID=PWEB_PRO

Perhaps this is to do with bug 194994?
Assignee: nobody → Olli.Pettay
Attached patch possible fixSplinter Review
This is the simplest fix. Other one would be to make nsDOMAttributeMap::mContent
strong ref, but since our DOM doesn't keep parent nodes etc. alive anyway when
having a reference to child, this should be enough. And this doesn't change the
behavior.
Attachment #302308 - Flags: superreview?(peterv)
Attachment #302308 - Flags: review?(peterv)
Comment on attachment 302308 [details] [diff] [review]
possible fix

Yeah, I'd say lets keep the strong references one-way for 1.9. In moz2 everything will be MMgc anyway.
Attachment #302308 - Flags: superreview?(peterv)
Attachment #302308 - Flags: superreview+
Attachment #302308 - Flags: review?(peterv)
Attachment #302308 - Flags: review+
Attachment #302308 - Flags: approval1.9?
Attachment #302445 - Flags: approval1.9+
Attachment #302308 - Flags: approval1.9?
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: blocking1.9? → in-testsuite+
Resolution: --- → FIXED
Crash Signature: [@nsDOMAttribute::GetValue(nsAString_internal&)]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.