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)

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

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

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.

This could be related to my changes from last night. I'm taking a look...

sairuh says that this is *not* consistently reproducible *all the time*. Not sure if this s'd be a blocker.

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.

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.

ok, reducing severity, starting carpools for the day.

Putting on [dogfood+] radar.

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?

Re-assigning bug to myself. I'll play around with this in the debug builds.

occurred again using winNT 2000.04.19.16-m16 (comm). crashed when going to www.amazon.com during the smoketesting.

also happens on mac 2000.04.19.16 commercial (same step, when loading www.amazon.com).

*** Bug 36319 has been marked as a duplicate of this bug. ***

Upping priority and setting milestone to M16...

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

*** Bug 36553 has been marked as a duplicate of this bug. ***

add dogfood keywork and url's

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/

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.

VERIFIED fixed on all platforms with the 2000042109 build.