When viewing retrogames.com, the apprunner generate a invalid access to memory (0x00000)

Yep. Big time crash and burn with Mar 22 build, Apprunner, all platforms. See Talkback Tracking ID CVU170TC when available. rickg, thoughts?

Clearing Milestone for don to re-set.

Re-assigned to karnaze@netscape.com and changed component to HTMLTables. Chris, this doesn't crash for me but the table layout is all whacky.

Just a quick note. I looked at this and the HTML in the page is 'inventive'. So, I think that the container tables are getting 'broken' in the parsing. However, I haven't narrowed it down to a clear case(s). More later.

Here is a test case (to be attached shortly) for www.retrogames.com. One of the sidebar tables is 'broken' in parsing. If you look at the test case (with short description) you'll see that it breaks on a fairly obscure condition. That, plus the, uh, 'free-style' HTML would seem to make this a low priority on the parser side (unless it highlights some bigger problem lurking around). (Tested with viewer.exe on Win95 using builds dated April 9 & 11 (optimized). If I remove the 'bad' table from the page, then I get pretty good 4.xP with two small (possible) bugs remaining: 1) a problem with vertical separation of <LI> elements, and (2) (perhaps just a quirk) a problem with table border color for border=0 (?).

Hmm ... this is now a crasher for M4 build viewer.exe on win95 for both http://www.retrogames.com http://bugzilla.mozilla.org/showattachment.cgi?attach_id=16 Both crashes report 'VIEWER caused an invalid page fault in module RAPTORHTMLPARS.DLL at 0137:0068124c.'

Well, I was getting ready to write, as someone aptly put it: "Duh! Take away my keyboard." I realized that I was *not* running M4; I was running M3. (Doh!) But then, I was playing with the test case *and* using M4 and I did in fact get a crash. Test case attached. Talkback dump floating around somewhere in space.

Updating QA Contact

Okay -- both Apr21 and Apr25 win95 opt builds can load www.retrogames.com sucessfully, with no major table bustage, but the two problems noted in my 04/13 note still present (that's good ;) The Apr21 build can also successfully load and display correctly http://bugzilla.mozilla.org/showattachment.cgi?attach_id=16 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=44 the test cases attached above. BUT ... the Apr25 build does (intermittently) CRASH on http://bugzilla.mozilla.org/showattachment.cgi?attach_id=44 The crash occurs in module RAPTORHTML.DLL at 0137:005a3eaf for the Apr25 (timestamp 25/04/99 9:07 AM). On one occasion, the crash was particularly severe: the DOS prompt from which viewer.exe was launched did not return, could not be interrupted by Ctrl-C or killing the window. I then shut down Win95, and, after it had terminated the DOS window, two successive "can't be shutdown" dialog boxes popped up referring to NSPR:EventReceiver and Mozilla:DNSEventHandler The clearest (to me) way to duplicate the crash is to successively _load_ (not back/forward) 'attach_id=16' and then 'attach_id=44' (repeat till "done").

It's asserting in the parser on my 4/27 WinNT debug build. To reproduce, follow the last paragraph of the previous comments. I'm Adding [CRASH] to the summary, changing the severity to critical and reassigning to Rick. NTDLL! 77f76148() nsDebug::Assertion(char * 0x0071767c, char * 0x0071766c, char * 0x00717630, int 1218) line 140 + 13 bytes SinkContext::End() line 1218 + 35 bytes HTMLContentSink::CloseHTML(HTMLContentSink * const 0x013d2ce0, const nsIParserNode & {...}) line 1707 CNavDTD::CloseHTML(const nsIParserNode & {...}) line 2227 + 31 bytes CNavDTD::CloseContainer(const nsIParserNode & {...}, nsHTMLTag eHTMLTag_unknown, int 0) line 2547 + 12 bytes CNavDTD::CloseContainersTo(int 0, nsHTMLTag eHTMLTag_unknown, int 0) line 2604 + 26 bytes CNavDTD::DidBuildModel(CNavDTD * const 0x013c9b60, unsigned int 0, int 1, nsIParser * 0x013d2b80, nsIContentSink * 0x013d2ce0) line 543 + 14 bytes nsParser::DidBuildModel(unsigned int 0) line 463 + 55 bytes nsParser::ResumeParse(nsIDTD * 0x00000000) line 804 nsParser::OnStopBinding(nsParser * const 0x013d2b84, nsIURL * 0x01306b30, unsigned int 0, unsigned short * 0x013c2e90) line 1026 + 17 bytes nsDocumentBindInfo::OnStopBinding(nsDocumentBindInfo * const 0x01306ae0, nsIURL * 0x01306b30, unsigned int 0, unsigned short * 0x013c2e90) line 2276 + 30 bytes OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x013c2e40) line 591 + 45 bytes StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x013c2e44) line 471 + 12 bytes PL_HandleEvent(PLEvent * 0x013c2e44) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x012bfe60) line 437 + 9 bytes _md_EventReceiverProc(void * 0x00020694, unsigned int 49275, unsigned int 0, long 19660384) line 799 + 9 bytes

This bug report is getting too long. However, in my tests parser never shows up. Everytime I run this, I crash after the presShell is getting destroyed. Troy -- can you please take a look? Here's the stack track I get (everytime): _free_dbg_lk(void * 0x0429ad90, int 65535) line 1027 + 26 bytes _free_dbg(void * 0x0429ad90, int 65535) line 970 + 13 bytes operator delete(void * 0x0429ad90) line 49 + 16 bytes nsHTMLBodyElement::`scalar deleting destructor'(unsigned int 1) + 34 bytes nsHTMLBodyElement::Release(nsHTMLBodyElement * const 0x0429ad90) line 581 + 102 bytes nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() line 2107 + 12 bytes nsHTMLHtmlElement::~nsHTMLHtmlElement() line 99 + 11 bytes nsHTMLHtmlElement::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsHTMLHtmlElement::Release(nsHTMLHtmlElement * const 0x042ae900) line 103 + 99 bytes nsDocument::~nsDocument() line 668 + 27 bytes nsMarkupDocument::~nsMarkupDocument() line 48 + 8 bytes nsHTMLDocument::~nsHTMLDocument() line 176 + 23 bytes nsHTMLDocument::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsDocument::Release(nsDocument * const 0x042ae4f0) line 785 + 102 bytes nsHTMLDocument::Release(nsHTMLDocument * const 0x042ae4f0) line 216 PresShell::~PresShell() line 551 + 18 bytes PresShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes PresShell::Release(PresShell * const 0x0429b080) line 485 + 34 bytes DocumentViewerImpl::~DocumentViewerImpl() line 216 + 18 bytes DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x042a9910) line 153 + 99 bytes nsWebShell::Embed(nsWebShell * const 0x01039bc0, nsIContentViewer * 0x042bb8f0, const char * 0x00000000, nsISupports * 0x00000000) line 713 + 27 bytes nsDocumentBindInfo::OnStartBinding(nsDocumentBindInfo * const 0x042ba050, nsIURL * 0x042b9420, const char * 0x042bb1e0) line 2180 + 36 bytes OnStartBindingProxyEvent::HandleEvent(OnStartBindingProxyEvent * const 0x042bb220) line 506 StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x042bb224) line 471 + 12 bytes PL_HandleEvent(PLEvent * 0x042bb224) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01010fd0) line 437 + 9 bytes _md_EventReceiverProc(HWND__ * 0x002e07b8, unsigned int 49349, unsigned int 0, long 16846800) line 799 + 9 bytes USER32! 77e713ed() 01010fd0()

With the latest source it's not crashing for me. I also ran it under Purify and there were no problems reported

Tested using Apprunner with 5/19 build on Win 95, Win NT, Win 98, Mac8.5 and Linux. No crashes. Verified bug fixed.