Closed Bug 26395 Opened 25 years ago Closed 25 years ago

Embedded null at end of HTML page causes assert.

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: e75644, Assigned: rickg)

References

(
URL
)

Details

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
updating component.  let me know if i guessed wrong.
Assignee: leger → rickg
Component: Browser-General → Parser
QA Contact: cbegle → janc
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.
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).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Marking Verified as invalid.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.