20891 - Assertion when displaying message

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[scottputterman]

I get the following assertion when displaying the message I'm about to attach.
I think it's because "mailbox://" appears in it.

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x10098d68, const char * 0x10098d58, const char
* 0x10098d2c, int 660) line 284 + 13 bytes
nsFilePath::nsFilePath(const char * 0x04a885c0, int 0) line 660 + 46 bytes
nsMailboxUrl::ParseUrl(const nsString & {""}) line 353 + 43 bytes
nsMailboxUrl::SetSpec(nsMailboxUrl * const 0x04a886a4, const char * 0x04a8a070)
line 361 + 35 bytes
nsMailboxService::NewURI(nsMailboxService * const 0x030edc08, const char *
0x04a8a070, nsIURI * 0x00000000, nsIURI * * 0x0012e96c) line 298
nsIOService::NewURI(const char * 0x04a8a070, nsIURI * 0x00000000, nsIURI * *
0x0012e96c, nsIProtocolHandler * * 0x00000000) line 218 + 35 bytes
nsIOService::NewURI(nsIOService * const 0x010b0950, const char * 0x04a8a070,
nsIURI * 0x00000000, nsIURI * * 0x0012e96c) line 226
mozTXTToHTMLConv::CheckURLAndCreateHTML(const nsAutoString & {"mailbox://"},
const nsAutoString & {""mailbox://""}, nsAutoString & {""}) line 367 + 33 bytes
mozTXTToHTMLConv::FindURL(const nsAutoString & {"!
PL_strcasestr(aListener->m_templateUri, "mailbox://")
"}, const unsigned int 68, const unsigned int 4294967295, nsAutoString & {""},
int & 78160908, int & 63) line 458 + 23 bytes
mozTXTToHTMLConv::ScanTXT(const nsAutoString & {"!
PL_strcasestr(aListener->m_templateUri, "mailbox://")
"}, unsigned int 4294967295) line 868 + 41 bytes
mozTXTToHTMLConv::ScanTXT(mozTXTToHTMLConv * const 0x04a8fcb0, const unsigned
short * 0x04a8a150, unsigned int 4294967295, unsigned short * * 0x0012f624) line
985 + 41 bytes
MimeInlineTextPlain_parse_line(char * 0x04a8a3b0, int 76, MimeObject *
0x04a866c0) line 178 + 63 bytes
MimeInlineText_rotate_convert_and_parse_line(char * 0x04a8a3b0, int 76,
MimeObject * 0x04a866c0) line 312 + 20 bytes
convert_and_send_buffer(char * 0x03a66448, int 76, int 1, int (char *, unsigned
int, void *)* 0x01909a20 MimeInlineText_rotate_convert_and_parse_line(char *,
int, MimeObject *), void * 0x04a866c0) line 151 + 15 bytes
mime_LineBuffer(const char * 0x0012f734, int 2, char * * 0x04a866e8, int *
0x04a866f0, unsigned int * 0x04a866f8, int 1, int (char *, unsigned int, void
*)* 0x01909a20 MimeInlineText_rotate_convert_and_parse_line(char *, int,
MimeObject *), void * 0x04a866c0) line 238 + 29 bytes
MimeInlineText_parse_decoded_buffer(char * 0x0012f734, int 2, MimeObject *
0x04a866c0) line 241 + 45 bytes
MimeLeaf_parse_buffer(char * 0x0012f734, int 2, MimeObject * 0x04a866c0) line
153 + 20 bytes
MimeMultipart_parse_child_line(MimeObject * 0x04a81210, char * 0x01196058, int
30, int 0) line 536 + 18 bytes
MimeMultipart_parse_line(char * 0x01196058, int 32, MimeObject * 0x04a81210)
line 220 + 22 bytes
convert_and_send_buffer(char * 0x01196058, int 32, int 1, int (char *, unsigned
int, void *)* 0x0190adf0 MimeMultipart_parse_line(char *, int, MimeObject *),
void * 0x04a81210) line 151 + 15 bytes
mime_LineBuffer(const char * 0x039b9130, int 32, char * * 0x04a81238, int *
0x04a81240, unsigned int * 0x04a81248, int 1, int (char *, unsigned int, void
*)* 0x0190adf0 MimeMultipart_parse_line(char *, int, MimeObject *), void *
0x04a81210) line 238 + 29 bytes
MimeObject_parse_buffer(char * 0x039b9130, int 32, MimeObject * 0x04a81210) line
223 + 49 bytes
MimeMessage_parse_line(char * 0x039b9130, int 32, MimeObject * 0x044c3d50) line
173 + 20 bytes
convert_and_send_buffer(char * 0x039b9130, int 32, int 1, int (char *, unsigned
int, void *)* 0x0190f990 MimeMessage_parse_line(char *, int, MimeObject *), void
* 0x044c3d50) line 151 + 15 bytes
mime_LineBuffer(const char * 0x03aa78a2, int 15867, char * * 0x044c3d78, int *
0x044c3d80, unsigned int * 0x044c3d88, int 1, int (char *, unsigned int, void
*)* 0x0190f990 MimeMessage_parse_line(char *, int, MimeObject *), void *
0x044c3d50) line 238 + 29 bytes
MimeObject_parse_buffer(char * 0x03aa5f70, int 22317, MimeObject * 0x044c3d50)
line 223 + 49 bytes
mime_display_stream_write(_nsMIMESession * 0x044c4580, const char * 0x03aa5f70,
int 22317) line 615 + 20 bytes
nsStreamConverter::OnDataAvailable(nsStreamConverter * const 0x044c6c60,
nsIChannel * 0x04bfeef0, nsISupports * 0x00000000, nsIInputStream * 0x04a7c748,
unsigned int 0, unsigned int 22317) line 642 + 24 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x04bfedd0,
nsIChannel * 0x04bfeef0, nsISupports * 0x00000000, nsIInputStream * 0x04a7c748,
unsigned int 0, unsigned int 22317) line 212 + 46 bytes
nsChannelListener::OnDataAvailable(nsChannelListener * const 0x04bfe860,
nsIChannel * 0x04bfeef0, nsISupports * 0x00000000, nsIInputStream * 0x04a7c748,
unsigned int 0, unsigned int 22317) line 1597
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x04a7e200)
line 370
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x04a7dfd0) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x04a7dfd0) line 522 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0105a650) line 483 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000104da, unsigned int 49483, unsigned int 0,
long 17147472) line 947 + 9 bytes
USER32! 77e71820()
0105a650()

Comment 1

[scottputterman]

Attachment: message for this bug.

Comment 2

[Ben Bucksch (:BenB)]

No MIME problem. We hand string the look like URI to NewURI in Necko now to
test, if they're valid. Feeding NewURI with "mailto://" should not "ASSERT".

Changing to Necko.

Comment 3

[lchiang]

What would happen in a release build?

Comment 4

[scottputterman]

the assertion wouldn't show up.  It didn't look like anything bad was happening,
so probably nothing.

Comment 5

[Warren Harris]

nsFilePath crap  ==> dougt

Comment 6

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 7

[Doug Turner (:dougt)]

will be fix by bug 22047.

Comment 8

[Doug Turner (:dougt)]

Evil nsFilePath crap.  This should be using nsIFile.  warren, will this be
fixed by your necko conversions?

Comment 9

[Warren Harris]

I hope so. Assign it to me if you like.

Comment 10

[Doug Turner (:dougt)]

as requested.

Comment 11

[Warren Harris]

We're deferring the nsIFile landing until M14, so this isn't going to make M13.

Comment 12

[Warren Harris]

I don't get this assertion now with the new nsIFile stuff -- either sending an 
attached file, or forwarding a message from my imap mailbox.

Comment 13

[lchiang]

par or suresh, can you verify this in a debug build? Thanks.

Comment 14

[scottputterman]

Sorry I wasn't clear.  It doesn't happen when attaching a message.  It happens
on the message I have attached to this bug report.  This still happens. The
easiest way to see this right now is to go to this bug in 5.0.  Make sure
mailnews is open.  Click on the 12/06/99 attachment above.  You will see this
assert.  I just duplicated this in my debug build from today.

One more thing is that the assert is within an ifdef XP_PC so you can only see
this on Windows.

Comment 15

[Warren Harris]

The problem here is that nsMailboxUrl::ParseUrl calls GetFilePath (the url is 
"mailbox://") and nsStdURL::GetFilePath returns "/" -- this then gets handed to 
the nsFilePath constructor which expects something of the form "C:\...".

So there are several problems here: First, GetFilePath probably isn't the right 
thing to call, particularly if handed to nsFilePath. Second, nsFilePath isn't 
really what we want to be calling anymore -- we should be using the new nsIFile 
stuff (but that's a much bigger changes). 

This transformation to native paths is handled correctly by the new 
nsIFileURL::GetFile method which returns an nsIFile for a url. The ideal 
solution would be to convert mailnews to nsIFile, but maybe a short-term fix is 
needed until then.

Handing this off to Andreas, but Scott: Take it back if you intend to fix 
mailnews to use nsIFile.

Comment 16

[Andreas Otte]

nsFileSpec can't handle empty paths and can't handle UNC paths, it simply
asserts (line 682 in nsFileSpec) if the second char is not a colon. It does not
even bother to check if there is a second char in the string.

I guess the assert is there for a reason, does anybody know why?

Best thing would be to convert to nsIFile.

Comment 17

[Andreas Otte]

Attachment: Short term patch to fix the problem

Comment 18

[Warren Harris]

I added bug 33451 to convert mailnews over to use nsIFile. Wishful thinking on 
my part.

Comment 19

[Andreas Otte]

This will have to wait for M16.

Comment 20

[Warren Harris]

Moving to M17 which is now considered part of beta2.

Comment 21

[Andreas Otte]

fix checked in.

Comment 22

[ppandit]

Using a debug mozilla build from 6/12/00.

Clicked on the 12/6/99 attachment putterman had provided. Still get the 
asseration. Clicked to Retry to get stack trace which is below. 

REOPENING for further investigation by developer.

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x0036320c, const char * 0x003631a8, const char 
* 0x00363174, int 100) line 242 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x0036320c, const char * 0x003631a8, const 
char * 0x00363174, int 100) line 300 + 21 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x033666e0, 
const char * 0x0012f908, int 1, const char * 0x1009abd8 gCommonEmptyBuffer, 
nsIChannel * 0x03e70f30, nsIStreamListener * * 0x0012f948, int * 0x0012f8ec) 
line 100 + 65 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x03e70f30, nsISupports * 
0x00000000) line 347 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x03e70870, 
nsIChannel * 0x03e70f30, nsISupports * 0x00000000) line 196 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x03e70cf0, 
nsIChannel * 0x03e70f30, nsISupports * 0x00000000) line 1168
InterceptStreamListener::OnStartRequest(InterceptStreamListener * const 
0x03d110b0, nsIChannel * 0x03e70f30, nsISupports * 0x00000000) line 1140
nsHTTPServerListener::FinishedResponseHeaders() line 1093 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x03ccba10, 
nsIChannel * 0x03bea494, nsISupports * 0x03e70f30, nsIInputStream * 0x03ccb98c, 
unsigned int 26381, unsigned int 2720) line 427 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03d10eb0) 
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03d12980) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x03d12980) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x010609a0) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00350102, unsigned int 49408, unsigned int 0, 
long 17172896) line 1032 + 9 bytes
USER32! 77e71820()
010609a0()

Comment 23

[Andreas Otte]

This is now something completely different, reassigning ...

Comment 24

[Gagan]

I agree this is a different assertion now. Looks like mscott to me...

Comment 25

[Scott MacGregor]

This assertion was filed before open attachment was actually implemented.  Now
that it's implemented I'm able to open text files just fine. 

Comment 26

[[e-mail] (gone - use [e-mail] instead)]

Verifying on Win2K, build 2000121204

Comment 27

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/6297acaa4e84
[fenix] Update Android Components version to 93.0.20210817143149. (https://github.com/mozilla-mobile/fenix/pull/20891)