[PP] Select a few msgs and delete may cause system hang 1999-05-17 Mac Release build Peter has also seen this bug 1) Start apprunner. Tasks | Messenger 2) Select the Inbox folder to display messages. I have about 200 messages in the Inbox. 3) Sort by Sender 4) Select a message further down the list 5) Shift+select to select a range of messages (I used a range of three messages) 6) Click delete toolbar button. Messages are deleted 7) UI comes back with a message selected. Reselect that message 8) Shift+select to select another range of messages (3) 9) Click delete toolbar button. I do this about 2 iterations and then my entire system hangs. No talkback stack traces, no MacsBugs. I have to do a hard boot on the Mac. I have been able to reproduce this consistently. I'm going to file this now as a platform parity bug. I will try this on Linux next to see if the same type of problem exists.

Oops. Wrong component. Should be front-end. Changing as such and reassign to phil for correct engineer.

Note: I have not been able to reproduce this on Linux. Appears to be fine. Peter - When you see this problem, do you also get a system lockup or are you able to get any macsbug log or talkback?

Reassign to ducarroz as P1 for M6.

I don't know why this hangs, but it's a fluke that delete even works in this case at all. Deleting after sorting isn't supported at the moment and it's just luck that it works in some cases(this was mentioned in some bug report back in M5). Try this without sorting. Or, try this with sorting and then display all of the messages you are going to delete(the reason this is a fluke is because the Mark Read command is making this work). If you can reproduce the hang in this case, let me know and I can work with Jean-Francois to figure this out.

adding myself to cc list.

I'll try it w/out sorting. I didn't understand your comment: "Or, try this with sorting and then display all of the messages you are going to delete(the reason this is a fluke is because the Mark Read command is making this work." Even if this (sort followed by delete) is a fluke and not supposed to work, if it can be done, someone will do it :-)

I just got my system (Mac) to lock up without having to sort by sender first. I'll be free between 11 and noon. I have meetings pretty much the rest of the day. Let me know if you want to see this problem.

Mark Read/Unread forces us to fill in the information that delete message after a sort was missing. That's why if you select 3 messages using shift-select, only the first and last one will get deleted. However, if you clicked on all 3 messages (actually, it's more accurate to say, if you changed the status of the 3 messages), then delete would work fine. I'd need Paul or Jean-Francois's help to look at this.

I will take a look at this...

Paul and I tried this and were unable to reproduce it. Lisa or Peter, when you get a chance, could you show this to us.

Lisa, I am not able to reproduce this problem on my Mac. Can you still reproduce this problem on your system? /peter

Lisa, Scott, and Paul was able to reproduce the problem on Lisa's Mac and my mac. They narrowed down the problem to a specific Return Receipt mail message. We gave Scott Putterman a copy of the Inbox and Inbox.msf file on disk and I plan to attached these files to this bug report.

On my Windows machine it won't even display this message and tempMessage.eml is a 0 byte file. Could it be that on the Mac it tries to layout a 0 byte file and hangs whereas on Windows it does nothing? cc'ing mscott and rhp

Deleting the .msf file didn't fix it. It's the message with messagekey 115126 which is the 2nd message in the unsorted view.

This message shows up fine in 4.5

I must have quite a few of these types of messages in my Inbox because I hit the system lockup quite often on the Mac with this Inbox. The interesting thing is how I got my local Inbox to get corrupted like this.

fyi I have not been able to attach the Inbox mail file to this bug report. It may be a file size limitation?? The Inbox is approx. 400k. I have tried to separate the bad message into its own mail folder but that fixes the file. Humm. for the current time, I can email you the file if you like.

My problem on Windows may not be legitimate. Or it may be the cause of the problem. The message I'm looking at doesn't have CR/LF in it so it can never find a valid line. I don't know if that's the way this file is, or if that's because this file came from a Mac and I'm running it on Windows.

As soon as I added the CR/LF to the file, it worked for me on Windows.

Even when using Lisa's inbox files, I still not able to reproduce the problem! I am using a debug build from the middle of this afternoon

Scott, it's normal you don't have the LF when you get the file from Mac as we use only CR as LINEBREAK on Mac.

JFD, I wonder if we could be getting bit by the PR_Open bug? that could be why the message (tempMessage.eml) is 0 bytes. I'll have a new version of mailbox protocol sans PR_Open tomorrow morning. but it would help if we could reproduce it on your debug build.

good point, I was testing with the fix for PR_Open. I will give a try again without it...

After removing the path for the PR_Open, I still not able to reproduce the problem. However I have noticed (with or withou PR_open fix) than offten when selecting one message or several message I get a strange Assertion message: Assertion: "xpconnect unable to init jscontext" (NS_SUCCEEDED(rv)) at file nsJSEnvironment.cpp, line 448 then the delete doesnt work, it doesn't delete all the selected message. Looks like we still have some XPConnect problem on Mac. I will update my tree when it turn green again and then give another try...

It's important that you click on the 2nd message first. The one from 3/22/99 at 16:37. Also, when we tried it on Peter's machine it was a copy from a Mac to a Mac. Is it possible that sending the attachment through Communicator and downloading it could have changed it in any way? I've often had CR/LF problems when downloading a text file.

JFD, the xpconnect assert is a XP bug. I have it filed on jband. I don't think he has checked in a fix yet. I think what you see there is a separate bug....I'll try to dig up the bug # & add it to this report.

"It's important that you click on the 2nd message first. The one from 3/22/99 at 16:37" How can I find the right one since Mac doesn't display the date anymore!!!

OK, that's a problem. Well, on every 5.0 build I've looked at, it's the 2nd message. It's a return receipt and it's from Lisa.

I was finaly able to reproduce this bug with the optimized build only. And the worst is that we cannot jump into Macsbug to see where we are! We hang after starting load the message url. The message frames are already draw but not it's content.

When I use a fresh commercial build to reproduce the hang, I have discover that the tmpMessage.eml file hasn't been created. Therefor I supected something with PR_Open but the know bug has been already fixed. Then I have added some trace message into msglocal.shlb to check the theory of an eventuel failure of PR_Open but now, with this new share lib, I get the tempMessage file and still crashing. The trace log I get is the following: nsMailboxProtocol::LoadURL, before PR_Delete nsMailboxProtocol::LoadURL, after PR_Delete and before PR_Open nsMailboxProtocol::LoadURL, after PR_Open, m_tempMessageFile = 110297264 nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::ReadMessageResponse, before PR_write nsMailboxProtocol::ReadMessageResponse, after PR_write nsMailboxProtocol::DoneReadingMessage, m_tempMessageFile= 110297264 nsMailboxProtocol::DoneReadingMessage, after PR_Close nsMailboxProtocol::DoneReadingMessage, before LoadURL nsMailboxProtocol::DoneReadingMessage, after LoadURL nsMailboxProtocol::DoneReadingMessage, end Some time, when loading the optimized build from the sym file, I was able to get the following macsbug stack trace: ... Net_PollSockets Net_ProcessNet Net_ProcessFile PR_Sleep Net_read_file_chunk -->crash The message that cause the hang is a multiple related part message. In occurance a MailServer return receipt. I am still investigating...

I re-tested this scenario in the PPC May 24 Seamonkey build (1999052408-m6), the problem still occurs. My system froze trying to load the return receipt mail mail message. On which return receipt mail message it frozed on appears to vary. Sometime it froze on the first return receipt message or it froze on the 7 mail message. When I'm frozen, I must reboot my computer. Force quit does not work. Today, I am testing on a PPC 9600/300 running Mac OS 8.5.1.

We can move this to M7 if the cause/fix is still under investigation at this time.

I will still working on it today as I think I become close to find what's append...

It's look like we died in the for loop of nsMimeURLUtils::ScanForURLs when scanning a line like (it's not always the same line!): "Original-Recipient: rfc882;ppandi@netscape.com\r" or "Reporter-MTA: dns dredd.mcom.com\r" Does it is a side effect of new smart URL detection Rich implemended beetween March 13 and 14? I will backup his changed to see if it works better!

Good detective job, Jean-Francois! Now I have to be a scmuck & tell you that I discovered this problem the other day looking at the purify log that suresh posted. Turns out, there is a char * variable called line which is not null terminated. the new code calls things like PL_strdup & PL_strlen on this non-null terminated string. nsMimeURLUtils::ScanForURLs calls FindAmbitiousMailToTag which has the memory corruption problems. My guess is that this is 'fatal' on the Mac. Could this be your problem? Rich is working on a post M6 fix. Rich, could you get an early bersion of the fix to Jean-Francois to see if it does fix the problem? We could then take the fix for M6. It may not but it is in the same part of the mime code that JFD sees the problem which makes me suspicious.

There is a possible bug in that code that I need to fix. When you scan for URL's there is a call to ItMatches(const char *line, const char *rep); that takes the line. It then will to a PL_strlen() on line, but there is a good chance that line could be non-null terminated. I just got this from mscott in purify this week. I need to rework the detection code to make a safe working copy, but it will have to be post M6 unless I can get the approval to checkin earlier. I will be out of the office for a about an hour and then I will make the fix and mail it to you JF. - rhp

Oops. I forgot, there is one more place in ScanForUrls that could cause the problem: ItMatches has the same memory corruption problem. If this is it, then my apologies for not connecting the dots with your bug Jean-Francois, I could have saved you some debugging code. =(

The problem has been introduced with the version 1.4 of nsMimeURLUtils.cpp.

Rich, here is a patch that works fine for me: Index: nsMimeURLUtils.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/mime/src/nsMimeURLUtils.cpp,v retrieving revision 1.9 diff -r1.9 nsMimeURLUtils.cpp 66c66 < FindAmbitiousMailToTag(const char *line) --- > FindAmbitiousMailToTag(const char *line, uint32 line_size) 76c76 < if ( !(atLoc = PL_strchr(line, '@')) ) --- > if ( !(atLoc = PL_strnchr(line, '@', line_size)) ) 80c80 < workLine = PL_strdup(line); --- > workLine = PL_strndup(line, line_size); 560c560 < mailToTag = FindAmbitiousMailToTag(input); --- > mailToTag = FindAmbitiousMailToTag(input, (uint32)input_size); 719c719 < mailToTag = FindAmbitiousMailToTag(cp); --- > mailToTag = FindAmbitiousMailToTag(cp, (uint32)end - (uint32)cp); Let me know if you see any problem...

ItMatches() shouldn't not cause any problem as it just reads the memory for few bytes even if the line isn't null terminated. But I will fix it as well...

Here is the full path that fix both FindAmbitiousMailToTag and ItMatches: Index: nsMimeURLUtils.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/mime/src/nsMimeURLUtils.cpp,v retrieving revision 1.9 diff -r1.9 nsMimeURLUtils.cpp 66c66 < FindAmbitiousMailToTag(const char *line) --- > FindAmbitiousMailToTag(const char *line, PRInt32 line_size) 76c76 < if ( !(atLoc = PL_strchr(line, '@')) ) --- > if ( !(atLoc = PL_strnchr(line, '@', line_size)) ) 80c80 < workLine = PL_strdup(line); --- > workLine = PL_strndup(line, line_size); 354c354 < ItMatches(const char *line, const char *rep) --- > ItMatches(const char *line, PRInt32 lineLen, const char *rep) 359d358 < PRInt32 lineLen = PL_strlen(line); 372c371 < GlyphHit(const char *line, char **outputHTML, PRInt32 *glyphTextLen) --- > GlyphHit(const char *line, PRInt32 line_size, char **outputHTML, PRInt32 *glyphTextLen) 375c374 < if ( ItMatches(line, ":-)") || ItMatches(line, ":)") ) --- > if ( ItMatches(line, line_size, ":-)") || ItMatches(line, line_size, ":)") ) 383c382 < else if ( ItMatches(line, ":-(") || ItMatches(line, ":(") ) --- > else if ( ItMatches(line, line_size, ":-(") || ItMatches(line, line_size, ":(") ) 391c390 < else if (ItMatches(line, ";-)")) --- > else if (ItMatches(line, line_size, ";-)")) 399c398 < else if (ItMatches(line, ";-P")) --- > else if (ItMatches(line, line_size, ";-P")) 560c559 < mailToTag = FindAmbitiousMailToTag(input); --- > mailToTag = FindAmbitiousMailToTag(input, (PRInt32)input_size); 578c577 < if ((do_glyph_substitution) && GlyphHit(cp, &glyphHTML, &glyphTextLen)) --- > if ((do_glyph_substitution) && GlyphHit(cp, (PRInt32)end - (PRInt32)cp, &glyphHTML, &glyphTextLen)) 719c718 < mailToTag = FindAmbitiousMailToTag(cp); --- > mailToTag = FindAmbitiousMailToTag(cp, (PRInt32)end - (PRInt32)cp);

<Great job everyone!>

Code reviewed by rhp and fix validated on Mac, Windows and Unix, Waiting for approval.

approved by chofmann, fix and check in

I've verified this fix in the 1999052516 build on Mac. Selecting that particular message no longer crashes. I also tested a bit with selecting several messages (using shift+select and ctrl+select) and deleting which is what I was originally doing when I reported this bug.