106527 - Parser hands the sink attributes with no name! [@ HTMLContentSink::AddAttributes][@ HTMLAttributesImpl::SetAttributeName]

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Håkan Waara]

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()

Comment 1

[Håkan Waara]

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

Comment 2

[Johnny Stenback (:jst)]

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

Comment 3

[R.K.Aa.]

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

Comment 4

[Markus Gerstel]

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

Comment 5

[Håkan Waara]

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

Comment 6

[Håkan Waara]

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.

Comment 7

[R.K.Aa.]

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

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 11

[Johnny Stenback (:jst)]

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

Comment 12

[Johnny Stenback (:jst)]

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

Comment 13

[R.K.Aa.]

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

Comment 14

[R.K.Aa.]

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

Comment 15

[Matthias Versen [:Matti]]

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

Comment 16

[R.K.Aa.]

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

Comment 17

[Matthias Versen [:Matti]]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Matthias Versen [:Matti]]

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

Comment 21

[Matthias Versen [:Matti]]

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

Comment 22

[Jacob Kjome]

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

Comment 23

[André Schild]

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

Comment 24

[greer]

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

Comment 25

[harishd]

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.

Comment 26

[Jay Patel [:jay]]

[e-mail]'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 [e-mail]
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...

Comment 27

[Johnny Stenback (:jst)]

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

Comment 28

[harishd]

This is not a topcrasher anymore. Removing topcrash keyword.

Comment 29

[greer]

Replacing the keywords for tracking in talkback.

Comment 30

[harishd]

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

Comment 31

[Moied]

Verified no crash on build ID 20011107