Closed
Bug 36362
Opened 24 years ago
Closed 24 years ago
Crash when loading after cnn.com or msn.com page view
Categories
(Core :: DOM: Navigation, defect, P3)
Core
DOM: Navigation
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: bugzilla, Assigned: nisheeth_mozilla)
References
()
Details
(Keywords: crash, regression, smoketest, Whiteboard: [dogfood+])
found this while testing opt comm linux bits, 2000.04.19.09-m16. will check other platforms soon. occurred while running thru smoketest 12, clicking the Back and Forward keys after viewing topsites. talkback report (this one occurred after clicking Fwd once): http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=96&cp=2&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=9004890 Call Stack: (Signature = nsHTMLInputElement::~nsHTMLInputElement() 0a0ddc59) nsHTMLInputElement::~nsHTMLInputElement() nsHTMLInputElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLDivElement::~nsHTMLDivElement() nsHTMLDivElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableCellElement::~nsHTMLTableCellElement() nsHTMLTableCellElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableRowElement::~nsHTMLTableRowElement() nsHTMLTableRowElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableSectionElement::~nsHTMLTableSectionElement() nsHTMLTableSectionElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableElement::~nsHTMLTableElement() nsHTMLTableElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableCellElement::~nsHTMLTableCellElement() nsHTMLTableCellElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableRowElement::~nsHTMLTableRowElement() nsHTMLTableRowElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableSectionElement::~nsHTMLTableSectionElement() nsHTMLTableSectionElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLTableElement::~nsHTMLTableElement() nsHTMLTableElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsBodyInner::~nsBodyInner() nsHTMLBodyElement::~nsHTMLBodyElement() nsHTMLBodyElement::Release() nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() nsHTMLHtmlElement::~nsHTMLHtmlElement() nsHTMLHtmlElement::Release() nsDocument::~nsDocument() nsMarkupDocument::~nsMarkupDocument() nsHTMLDocument::~nsHTMLDocument() nsDocument::Release() nsHTMLDocument::Release() nsCOMPtr_base::~nsCOMPtr_base() DocumentViewerImpl::~DocumentViewerImpl() DocumentViewerImpl::Release() nsCOMPtr_base::assign_with_AddRef() nsDocShell::SetupNewViewer() nsWebShell::SetupNewViewer() nsDocShell::CreateContentViewer() nsDSURIContentListener::DoContent() nsDocumentOpenInfo::DispatchContent() nsDocumentOpenInfo::OnStartRequest() InterceptStreamListener::OnStartRequest() nsHTTPServerListener::FinishedResponseHeaders() nsHTTPServerListener::OnDataAvailable() nsOnDataAvailableEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x4064452a) libglib-1.2.so.0 + 0xfbe6 (0x40645be6) libglib-1.2.so.0 + 0x101a1 (0x406461a1) libglib-1.2.so.0 + 0x10341 (0x40646341) libgtk-1.2.so.0 + 0x8c209 (0x4056d209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x402f21eb)
|
Reporter | |
Comment 1•24 years ago
|
||
the talkback report for when i clicked Back (and got a crash) is essentially the same: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=96&cp=1&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=9004948
|
|
Reporter | |
Comment 2•24 years ago
|
||
this is kinda tricky, but i got the same trace when trying to go to http://developer.netscape.com/ using the opt comm m16 bits on Mac and winNT, 2000.04.19.10/09... Mac: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=102&cp=1&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=9009412 WinNT: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=102&cp=2&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=9009360
Severity: critical → blocker
OS: Linux → All
Hardware: PC → All
Summary: Back/Fwd result in erratic crashes → Back/Fwd result in erratic crashes; developer.netscape.com
|
||
Comment 3•24 years ago
|
||
sairuh, do you only crash when gong back/to developer.netscape.com? I ask becuase we put that page in there b/c it's a frames page. We also knew that w/ travis' recent big changes to webshell that Session History was going to choke on frames pages until radha finishes the work to hook up to new SH to the new Webshell stuff. I just mention this cuz it's kinda unfair to call it a smoketest blocker for those reasons.
|
Assignee | |
Comment 4•24 years ago
|
||
This could be related to my changes from last night. I'm taking a look...
|
||
Comment 5•24 years ago
|
||
sairuh says that this is *not* consistently reproducible *all the time*. Not sure if this s'd be a blocker.
|
|
Assignee | |
Comment 6•24 years ago
|
||
I just tried to reproduce this also and failed using today's optimized bits for NT. I, too, don't think that this should be on the blocker list.
|
|
Reporter | |
Comment 7•24 years ago
|
||
after chatting w/radha, we found a reproducible case (on linux, using 2000.04.19.09-m16): 0. create/launch a fresh profile. 1. in the Location field, enter my.netscape.com, click enter to load it. 2. in the Location field, enter www.cnn.com, click enter to load it. 3. in the Location field, enter developer.netscape.com, click enter to load it. result: browser crashes. claudius, thx for the info --developer.netscape.com might indeed be the culprit --feel free to bump down the severity on this one.
|
||
Comment 8•24 years ago
|
||
ok, reducing severity, starting carpools for the day.
Severity: blocker → critical
Keywords: smoketest → regression
|
|
||
Comment 10•24 years ago
|
||
SH is nowhere in the stack trace. I crashed few times 2/3 when trying to load developer.netscape.com and the opt build showed just GKHTML.dll. Nisheeth, do you want to own this and take a closer look?
|
|
Assignee | |
Comment 11•24 years ago
|
||
Re-assigning bug to myself. I'll play around with this in the debug builds.
Assignee: radha → nisheeth
|
|
Reporter | |
Comment 12•24 years ago
|
||
occurred again using winNT 2000.04.19.16-m16 (comm). crashed when going to www.amazon.com during the smoketesting.
|
|
Reporter | |
Comment 13•24 years ago
|
||
also happens on mac 2000.04.19.16 commercial (same step, when loading www.amazon.com).
Keywords: smoketest
|
||
Comment 14•24 years ago
|
||
*** Bug 36319 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 15•24 years ago
|
||
Upping priority and setting milestone to M16...
Status: NEW → ASSIGNED
Target Milestone: --- → M16
|
|
||
Comment 16•24 years ago
|
||
people are pretty easily able to reproduce today by going between various web sites; check duplicate bugs of this and other duplicate bugs for specific web sites
|
|
||
Comment 17•24 years ago
|
||
*** Bug 36553 has been marked as a duplicate of this bug. ***
|
||
Comment 19•24 years ago
|
||
Changing summary from "Back/Fwd result in erratic crashes; developer.netscape.com" -- the bug lies in teardown of the content for http://www.msn.com/ or http://www.cnn.com/
Summary: Back/Fwd result in erratic crashes; developer.netscape.com → Crash when loading after cnn.com or msn.com page view
|
|
Assignee | |
Comment 20•24 years ago
|
||
I've checked in the fix for this. The special implementation of Release() on the form elements was setting the ref count on the element to 0 before deleting it. This would cause recursion back into the element's destructor when functions further up in the call stack released their reference to the element being destroyed. Now, the Release() method on the form elements leaves the ref count at 1 before deleting the form element and avoids the recursion into the element's destructor.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
|
|
||
Comment 21•24 years ago
|
||
VERIFIED fixed on all platforms with the 2000042109 build.
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in
before you can comment on or make changes to this bug.
Description
•