this is on a April 25 8pm build. apprunner -mail click on a folder with messages click on a subject line to display that message abort. here the stack: #0 0x40c0d6a1 in ?? () from /lib/libc.so.6 #1 0x40c0e6df in ?? () from /lib/libc.so.6 #2 0x408f001c in PR_Assert (s=0x410a5abb "line && *line", file=0x410a5a94 "mimemsg.cpp", ln=112) at prlog.c:480 #3 0x410906b1 in MimeMessage_parse_line (line=0x85d80f8 "", length=38, obj=0x847fbe0) at mimemsg.cpp:112 #4 0x41098a0d in convert_and_send_buffer (buf=0x85d80f8 "", length=38, convert_newlines_p=1, per_line_fn=0x41090664 <MimeMessage_parse_line(char *, int, MimeObject *)>, closure=0x847fbe0) at mimebuf.cpp:148 #5 0x41098c4d in mime_LineBuffer (net_buffer=0x806ec28 "", net_buffer_size=3130, bufferP=0x847fc08, buffer_sizeP=0x847fc10, buffer_fpP=0x847fc18, convert_newlines_p=1, per_line_fn=0x41090664 <MimeMessage_parse_line(char *, int, MimeObject *)>, closure=0x847fbe0) at mimebuf.cpp:235 #6 0x410945bd in MimeObject_parse_buffer (buffer=0x806ec08 "From - Fri Mar 19 11:57:00 1999\n", size=3162, obj=0x847fbe0) at mimeobj.cpp:218 #7 0x4109951e in mime_display_stream_write (stream=0x847fc40, buf=0x806ec08 "From - Fri Mar 19 11:57:00 1999\n", size=3162) at mimemoz2.cpp:271 #8 0x4107f257 in MimePluginInstance::Write (this=0x8605678, aBuf=0x806ec08 "From - Fri Mar 19 11:57:00 1999\n", aCount=3162, aWriteCount=0xbffff474) at plugin_inst.cpp:382 #9 0x40238891 in plugin_stream_write (stream=0x847fc88, str=0x806ec08 "From - Fri Mar 19 11:57:00 1999\n", len=3162) at cvplugin.cpp:61 #10 0x401a1bae in net_read_file_chunk (cur_entry=0x86036e8) at mkfile.c:956 #11 0x401a2549 in net_ProcessFile (cur_entry=0x86036e8) at mkfile.c:1327 #12 0x4025846f in NET_ProcessNet (ready_fd=0x0, fd_type=1) at mkgeturl.c:3355 #13 0x40260351 in NET_PollSockets () at mkselect.c:298 #14 0x402812a2 in nsNetlibService::NetPollSocketsCallback (aTimer=0x84c5330, aClosure=0x8123c50) at nsNetService.cpp:1263 #15 0x4016ade9 in TimerImpl::FireTimeout (this=0x84c5330) at nsTimer.cpp:73 #16 0x4016b2d2 in nsTimerExpired (aCallData=0x84c5330) at nsTimer.cpp:189 #17 0x40a98c11 in ?? () from /usr/lib/libglib-1.2.so.0 #18 0x40a97dd2 in ?? () from /usr/lib/libglib-1.2.so.0 #19 0x40a983bb in ?? () from /usr/lib/libglib-1.2.so.0 #20 0x40a98571 in ?? () from /usr/lib/libglib-1.2.so.0 #21 0x409bf15b in ?? () from /usr/lib/libgtk-1.2.so.0 #22 0x400a28a8 in ?? () from /builds/sspitzer/MOZILLA/04.25.1999/20.06/mozilla/dist/bin/libwidgetgtk.so #23 0x40019d11 in ?? () from /builds/sspitzer/MOZILLA/04.25.1999/20.06/mozilla/dist/bin/libnsappshell.so #24 0x804b394 in main (argc=1, argv=0xbffffa54) at nsAppRunner.cpp:438 I'm at home, so I haven't tested it on windows yet.

I can't get apprunner to load folders this morning, but I'm not seeing this rendering messages in viewer. - rhp

After today's checkin's, I want to see if this still happens. - rhp

I'm still seeing this. (my build from 4:30 am April 27th still aborts.) I've tried to remove all the summary files (.msf) and it still happens. Assertion failure: line && *line, at mimemsg.cpp:112 Abort (core dumped) Is anyone else seeing this?

Would a PR_ASSERT (which kills the app for debug builds) kill the app for a release build? Stacy is running linux builds and trying to display messages this morning. She doesn't crash but she does get XML parse errors when trying to display the messages. I wonder what she is seeing is the same problem in this bug but because the assert doesn't kill the app it keeps going and thus the parse error. Rich, I hope you don't mind but I'm going to bump the priority up two notches on this. this is pretty imporant for M5. Unfortunately my Linux build has been DOA yesterday and today so I haven't been able to see this for myself yet. However, Seth, can you look at the file: "C:\\mail.xml" and "C:\\email.html" (platform friendly names? =)) after trying do display a message and see if the contents look valid. The first one is the header xml stuff and the xecond file is the message body.

Rich, I just checked on Seth's machine and we are in fact writing out the correct message into tempMessage.eml in the temp directory. This is the file I then give to you to display. Both the mail.xml and email.html files that are generated are coming up blank. any ideas?

I'm not seeing a crash, but I am seeing a parsing error in the April 27 build, described in http://bugzilla.mozilla.org/show_bug.cgi?id=4886. Not sure which bug it belongs in.

I'm not seeing a crash, but I am seeing a parsing error in the April 27 build, described in http://bugzilla.mozilla.org/show_bug.cgi?id=4886. Not sure which bug it belongs in.

Can someone save a message file to disk as a .eml file and load it into viewer. I haven't touched the code that is failing here and I am kind of skeptical that its a libmime bug (at least for now :-) You can also load ~rhp/mhtml/RFC822-1.eml into viewer and this should display a message. - rhp

PR_ASSERTs are a no-op on release builds, that's why stacy sees different behavior

~rhp/mhtml/RFC822-1.eml works for me in viewer, but /usr/tmp/tempMessage.eml in viewer causes the same abort / assertion that I see in apprunner. I've copied it to /u/sspitzer/tempMessage.eml

Using 4.27 linux build I am indeed crashing on display message, usually can display one message then crash on the second one displayed.

Also, can someone on Linux try loading the problem email message into viewer with the following arguments: file://tempMessage.eml?header=only file://tempMessage.eml?header=none I'm still trying to figure out what is going on here. - rhp

*doh* I think this is my bug. rich noticed some null bytes getting written out the file we use to display the message. I went back and re-audited my code and found code like the following: if (line) PR_Write(m_tempMessageFile,(void *) line,PL_strlen(line)); PR_Write(m_tempMessageFile, (void *) MSG_LINEBREAK, PL_strlen(CRLF)); Note the second PR_Write is taking the length of CRLF (which is 2) instead of the length of the linebreak which is 1 on linux. I believe this should fix the problem. I'm going to check in the fix and once my linux build is back on its feet (hopefully very soon), I'll verify that it does indeed fix the problem. This would also explain the problem Paul Hangas and Jean-Francois are seeing on the mac when they try to display messages as well. Re-assigning the bug back to me.

mscott's fix for Linux works. I've just checked it in. marking bug as fixed.

damn. before, clicking on any message would cause a crash. now, clicking on the first one works, but the second crashes. (just like laurel reported) It's got a different stack trace, so I opened a new bug: #5572

Peter - can you verify when you're back at work?

Waiting for next good Linux build before I can verify.

Verified in the April 29 Linux build (build id 1999042908). I was not able to reproduce problem.

Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.