22061 - Assertion in nsDataHandler::NewURI() when loading message

Status: VERIFIED DUPLICATE of bug 22215

(MailNews Core :: Backend, defect, P3)

Description

[kinmoz]

The following assertion is thrown when loading the attatched message via IMAP in
my 12/17/99 WinNT debug build.



NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x00ef9530, const char * 0x00ef9524, const char
* 0x00ef94ec, int 81) line 186 + 13 bytes
nsDataHandler::NewURI(nsDataHandler * const 0x03a739e0, const char * 0x0400e4e0,
nsIURI * 0x03aedf20, nsIURI * * 0x0012f544) line 81 + 29 bytes
nsIOService::NewURI(const char * 0x0400e4e0, nsIURI * 0x03aedf20, nsIURI * *
0x0012f544, nsIProtocolHandler * * 0x00000000) line 218 + 35 bytes
nsIOService::NewURI(nsIOService * const 0x00c78930, const char * 0x0400e4e0,
nsIURI * 0x03aedf20, nsIURI * * 0x0012f544) line 226
NS_NewURI(nsIURI * * 0x0012f544, const char * 0x0400e4e0, nsIURI * 0x03aedf20)
line 50 + 35 bytes
NS_NewURI(nsIURI * * 0x0012f544, const nsString & {...}, nsIURI * 0x03aedf20)
line 63 + 17 bytes
HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4004 + 29
bytes
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x03aee6d0, const nsIParserNode
& {...}) line 2818 + 12 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x04000190) line 3110 + 28 bytes
CNavDTD::HandleScriptToken(const nsIParserNode * 0x04000190) line 1792 + 12
bytes
CNavDTD::OpenContainer(const nsIParserNode * 0x04000190, nsHTMLTag
eHTMLTag_script, int 1, nsEntryStack * 0x00000000) line 2824 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x03af8890, nsHTMLTag eHTMLTag_script,
nsIParserNode * 0x04000190) line 1048 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x03af8890) line 1352 + 22 bytes
CNavDTD::HandleToken(CNavDTD * const 0x03a7c470, CToken * 0x03af8370, nsIParser
* 0x03aee9b0) line 751 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x03a7c470, nsIParser * 0x03aee9b0,
nsITokenizer * 0x03a7c050, nsITokenObserver * 0x00000000, nsIContentSink *
0x03aee6d0) line 523 + 20 bytes
nsParser::BuildModel() line 1040 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 966 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x03aee9b4, nsIChannel * 0x03aed9f0,
nsISupports * 0x00000000, nsIInputStream * 0x03aed908, unsigned int 0, unsigned
int 36932) line 1326 + 19 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x03ae9060,
nsIChannel * 0x03aed9f0, nsISupports * 0x00000000, nsIInputStream * 0x03aed908,
unsigned int 0, unsigned int 36932) line 1456 + 43 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03aeddc0,
nsIChannel * 0x03aed9f0, nsISupports * 0x00000000, nsIInputStream * 0x03aed908,
unsigned int 0, unsigned int 36932) line 216 + 46 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03aed7b0)
line 370
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03aed760) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x03aed760) line 522 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c42f90) line 483 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0053050a, unsigned int 49395, unsigned int 0,
long 12857232) line 947 + 9 bytes
USER32! 77e71250()
00c42f

Comment 1

[kinmoz]

Attachment: Test case

Comment 2

[Phil Peterson]

Rich, are you generating the data: URL? (I'm assuming that's what an
nsDataHandler does)

Comment 3

[rhp (gone)]

It may not look like it, but this is the same problem as bug #22215. This is an
issue with us not being able to write all the data we have to the output
stream.

- rhp

*** This bug has been marked as a duplicate of 22215 ***

Comment 4

[pmock]

Changing qa assigned to [e-mail]

Comment 5

[lchiang]

ok, we'll verify this case when the other one is addressed.

Comment 6

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/da47adc78bf6
[fenix] Close https://github.com/mozilla-mobile/fenix/issues/22061: Let TabSorter decide if title header should be shown in tabs tray