26395 - Embedded null at end of HTML page causes assert.

Status: VERIFIED INVALID

(Core :: DOM: HTML Parser, defect, P3)

Description

[e75644]

The "possible embedded null in append" assert is caused by www.abcnews.com, 
which seems to have null at the end of the page. An earlier debug-note says 
"Null found at buffer[2384] provided by netlib...". I'm not sure if this is an 
actual bug, at least in this incarnation it's more a web-design glitch, but it 
causes an assert at any rate.

NTDLL! 77f762e8()
nsDebug::Assertion(char * 0x1009d3d0, char * 0x1009d3c0, char * 0x1009d39c, int 
1184) line 189 + 13 bytes
nsDebug::WarnIfFalse(char * 0x1009d3d0, char * 0x1009d3c0, char * 0x1009d39c, 
int 1184) line 245 + 21 bytes
nsString::Append(unsigned short * 0x029b3f08, int 3145) line 1184 + 31 bytes
nsScanner::Append(char * 0x03507f88, unsigned int 3145) line 299
nsParser::OnDataAvailable(nsParser * const 0x0282f8bc, nsIChannel * 0x02be3bd0, 
nsISupports * 0x00000000, nsIInputStream * 0x031f1584, unsigned int 0, unsigned 
int 3145) line 1369
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x031f0850, 
nsIChannel * 0x02be3bd0, nsISupports * 0x00000000, nsIInputStream * 0x031f1584, 
unsigned int 0, unsigned int 3145) line 256 + 46 bytes
InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 
0x031f1580, nsIChannel * 0x02be3bd0, nsISupports * 0x00000000, nsIInputStream * 
0x031db128, unsigned int 0, unsigned int 3145) line 1122
nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const 
0x031dbea0, nsIChannel * 0x031ecd34, nsISupports * 0x02be3bd0, nsIInputStream * 
0x031db128, unsigned int 56940, unsigned int 3145) line 195 + 58 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03335a60) 
line 370
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03335ab0) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x03335ab0) line 526 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00fd4e10) line 487 + 9 bytes
_md_EventReceiverProc(void * 0x00b50274, unsigned int 49533, unsigned int 0, 
long 16600592) line 975 + 9 bytes

Comment 1

[cbegle]

updating component.  let me know if i guessed wrong.

Comment 2

[e75644]

May or may not be related, while trying to reproduce this bug (Succeeded) on 
first time the next page I loaded on ABCnews broke up in middle and Mozilla 
started refusing to load more pages, and on second try with fresh start I got:

nsCOMPtr<nsProxyObject>::assign_with_AddRef(nsISupports * 0x02eb4e50) line 786 + 
9 bytes
nsCOMPtr<nsProxyObject>::operator=(nsProxyObject * 0x02eb4e50) line 527
nsProxyObjectCallInfo::nsProxyObjectCallInfo(nsProxyObject * 0x02eb4e50, 
nsXPTMethodInfo * 0x011bc370, unsigned int 3, nsXPTCVariant * 0x02d3be70, 
unsigned int 4, PLEvent * 0x02d39780) line 70
nsProxyObject::Post(unsigned int 3, nsXPTMethodInfo * 0x011bc370, 
nsXPTCMiniVariant * 0x017efdf0, nsIInterfaceInfo * 0x02d43c60) line 386 + 57 
bytes
nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x02eb4c90, unsigned 
short 3, const nsXPTMethodInfo * 0x011bc370, nsXPTCMiniVariant * 0x017efdf0) 
line 394 + 55 bytes
PrepareAndDispatch(nsXPTCStubBase * 0x02eb4c90, unsigned int 3, unsigned int * 
0x017efea4, unsigned int * 0x017efe90) line 100 + 31 bytes
SharedStub() line 125

Neither incident seems very reproducable, but I'm entering said bugs here 
anyway, as they may be related.

Comment 3

[rickg]

The assertion is only for debug purposes. The message indicates that we "see" a 
null, but the parsing engine is fully capable of dealing with them (ignoring).

Comment 4

[leger]

Marking Verified as invalid.