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

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
11 years ago
2 months ago

People

(Reporter: cbook, Assigned: smaug)

Tracking

({crash})

Trunk
x86
All
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, )

Attachments

(3 attachments)

Reporter

Description

11 years ago
Posted 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.
Reporter

Updated

11 years ago
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&)]

Comment 2

11 years ago
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

Updated

11 years ago
Assignee: nobody → Olli.Pettay
Assignee

Comment 3

11 years ago
Posted 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+
Assignee

Updated

11 years ago
Attachment #302308 - Flags: approval1.9?
Assignee

Comment 5

11 years ago

Updated

11 years ago
Attachment #302445 - Flags: approval1.9+

Updated

11 years ago
Attachment #302308 - Flags: approval1.9?
Assignee

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.9? → in-testsuite+
Resolution: --- → FIXED
Crash Signature: [@nsDOMAttribute::GetValue(nsAString_internal&)]
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.