This is happening for me constantly while loading www.dn.se on startup. HTMLContentSink::AddAttributes(const nsIParserNode & {...}, nsIHTMLContent * 0x044785e0, int 0) line 809 + 6 bytes SinkContext::OpenContainer(const nsIParserNode & {...}) line 1492 + 20 bytes HTMLContentSink::OpenContainer(HTMLContentSink * const 0x043e1b80, const nsIParserNode & {...}) line 3423 + 18 bytes CNavDTD::OpenContainer(const nsCParserNode * 0x0251bb50, nsHTMLTag eHTMLTag_td, int 1, nsEntryStack * 0x00000000) line 3450 + 31 bytes CNavDTD::HandleDefaultStartToken(CToken * 0x025c59b8, nsHTMLTag eHTMLTag_td, nsCParserNode * 0x0251bb50) line 1302 + 20 bytes CNavDTD::HandleStartToken(CToken * 0x025c59b8) line 1715 + 22 bytes CNavDTD::HandleToken(CNavDTD * const 0x04399650, CToken * 0x025c59b8, nsIParser * 0x043e1ef0) line 881 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x04399650, nsIParser * 0x043e1ef0, nsITokenizer * 0x043999b0, nsITokenObserver * 0x00000000, nsIContentSink * 0x043e1b80) line 517 + 20 bytes nsParser::BuildModel() line 1965 + 34 bytes nsParser::ResumeParse(int 1, int 0) line 1831 + 11 bytes nsParser::OnDataAvailable(nsParser * const 0x043e1ef4, nsIRequest * 0x043a1ad0, nsISupports * 0x00000000, nsIInputStream * 0x04399240, unsigned int 16384, unsigned int 16384) line 2486 + 19 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x043bcb80, nsIRequest * 0x043a1ad0, nsISupports * 0x00000000, nsIInputStream * 0x04399240, unsigned int 16384, unsigned int 16384) line 259 + 46 bytes nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x043f7930, nsIRequest * 0x043a1ad0, nsISupports * 0x00000000, nsIInputStream * 0x043c3840, unsigned int 16384, unsigned int 16384) line 56 + 51 bytes nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x043a1ad4, nsIRequest * 0x043c35d4, nsISupports * 0x00000000, nsIInputStream * 0x043c3840, unsigned int 16384, unsigned int 16384) line 2359 + 57 bytes nsOnDataAvailableEvent::HandleEvent() line 193 + 70 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x043bd384) line 80 PL_HandleEvent(PLEvent * 0x043bd384) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00a9c690) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00000f30, unsigned int 55371, unsigned int 0, long 11126416) line 1071 + 9 bytes KERNEL32! bff7363b() KERNEL32! bff94407() 006e8b5a()

Before the crash, I get this assertion too: ###!!! ASSERTION: Atom requested for empty string!: 'Error', file C:\mozilla\moz \mozilla\mozilla\xpcom\ds\nsAtomTable.cpp, line 277

Harish, why do we have attributes with no name? That needs to be fixed.

is this perhaps what happens in bug 106452, bug 106465, bug 106467

rkaa: I think you are right. see backtrace in bug 106452

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

We're crashing everywhere. Some people even report crashes on slashdot, that probably are related. I'll take the step and upgrade this to smoketest blocker.

In what looks like another duplicate (bug 106532) Akkana writes: "Jesup says the asserts are caused by the checkin for bug 69468."

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

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

Why do we not want to allow an atom representing the empty string?

I'm checking in a fix for this...

Crash fixed, leaving bug open to fix the empty attribute name problem.

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

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

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

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

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

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

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

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

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

I'm seeing something curious that isn't an immediate crash, but I wonder if it is related to this: Using build 2001102509 on Win2k (SP2) 1. Start Mozilla 2. Load a page, then close Mozilla (no crash yet) 3. Start Mozilla 4. Load a page, then close Mozilla (CRASH!) 5. Repeat steps 3 and 4 and you will now crash every time Talkback ID: TB37183191Y Is this related or a new bug? Jake

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

Ading keywords, updating summary and cc'ing talkback for tracking.

greer: I believe jst checked in a fix for the crash. Please verify this with a recent build and remove topcrash keyword if it isn't crashing. thanx.

hoju@visi.com's crash is different...so please log a new bug for it. here's the info anyway...in case anyone is curious to see it: Incident ID 37183191 Stack Signature ntdll.dll + 0x4b892 (0x77fcb892) 1123c508 Bug ID Trigger Time 2001-10-25 11:54:14 Email Address hoju@visi.com URL visited http://www.microsoft.com/ User Comments After going to microsoft.com, closed mozilla. It crashed upon closing. The error box that windows popped up says: NSPR:EventReciever: mozilla.exe jake Build ID 2001102509 Product ID MozillaTrunk Platform ID Win32 Trigger Reason Access violation Stack Trace ntdll.dll + 0x4b892 (0x77fcb892) ntdll.dll + 0x4b733 (0x77fcb733) MSVCRT.DLL + 0x1d92 (0x78001d92) PR_Free [../../../../pr/src/malloc/prmem.c, line 84] PR_DestroyCondVar [../../../../../pr/src/threads/combined/prucv.c, line 523] PL_DestroyEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 619] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 603] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] nsEventQueueImpl::ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\nsEventQueue.cpp, line 389] All the crashes reported on MozillaTrunk with the stack signatures originally posted were with the 20011024 build...I don't see any crashes with newer builds. Marking this fixed...

This is not fixed, the crash mentioned in this bug is fixed, but this bug is not fixed yet. Reopening.

This is not a topcrasher anymore. Removing topcrash keyword.

Replacing the keywords for tracking in talkback.

Opened up bug 109152 for the remaining issue. Since we don't crash anymore closing out this bug.

Verified no crash on build ID 20011107