Closed
Bug 6628
Opened 25 years ago
Closed 25 years ago
[PP] Specific message selected causes system hang
Categories
(SeaMonkey :: MailNews: Message Display, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M6
People
(Reporter: lchiang, Assigned: bugzilla)
Details
Attachments
(1 file)
(deleted),
application/octet-stream
|
Details |
[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.
Assignee: putterman → phil
Component: Address Book → Front End
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?
Updated•25 years ago
|
Assignee: phil → ducarroz
Priority: P3 → P1
Target Milestone: M6
Comment 3•25 years ago
|
||
Reassign to ducarroz as P1 for M6.
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•25 years ago
|
||
I will take a look at this...
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
Lisa,
I am not able to reproduce this problem on my Mac. Can you still reproduce this
problem on your system? /peter
Comment 12•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
Comment 14•25 years ago
|
||
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
Comment 15•25 years ago
|
||
Deleting the .msf file didn't fix it. It's the message with messagekey 115126
which is the 2nd message in the unsorted view.
Comment 16•25 years ago
|
||
This message shows up fine in 4.5
Summary: [PP] Select a few msgs and delete may cause system hang → [PP] Specific message selected causes system hang
Reporter | ||
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
As soon as I added the CR/LF to the file, it worked for me on Windows.
Assignee | ||
Comment 21•25 years ago
|
||
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
Assignee | ||
Comment 22•25 years ago
|
||
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.
Comment 23•25 years ago
|
||
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.
Assignee | ||
Comment 24•25 years ago
|
||
good point, I was testing with the fix for PR_Open. I will give a try again without it...
Assignee | ||
Comment 25•25 years ago
|
||
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...
Comment 26•25 years ago
|
||
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.
Comment 27•25 years ago
|
||
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.
Assignee | ||
Comment 28•25 years ago
|
||
"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!!!
Comment 29•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Whiteboard: Working on it, will takes time...
Assignee | ||
Comment 30•25 years ago
|
||
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.
Assignee | ||
Comment 31•25 years ago
|
||
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...
Comment 32•25 years ago
|
||
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.
Reporter | ||
Comment 33•25 years ago
|
||
We can move this to M7 if the cause/fix is still under investigation at this
time.
Assignee | ||
Comment 34•25 years ago
|
||
I will still working on it today as I think I become close to find what's append...
Assignee | ||
Comment 35•25 years ago
|
||
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!
Comment 36•25 years ago
|
||
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.
Comment 37•25 years ago
|
||
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
Comment 38•25 years ago
|
||
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. =(
Assignee | ||
Updated•25 years ago
|
Whiteboard: Working on it, will takes time... → We found the problem, fix will come very soon...
Assignee | ||
Comment 39•25 years ago
|
||
The problem has been introduced with the version 1.4 of nsMimeURLUtils.cpp.
Assignee | ||
Comment 40•25 years ago
|
||
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...
Assignee | ||
Comment 41•25 years ago
|
||
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...
Assignee | ||
Updated•25 years ago
|
Whiteboard: We found the problem, fix will come very soon... → Get a fix, waiting for code review...
Assignee | ||
Comment 42•25 years ago
|
||
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);
Reporter | ||
Comment 43•25 years ago
|
||
<Great job everyone!>
Assignee | ||
Comment 44•25 years ago
|
||
Code reviewed by rhp and fix validated on Mac, Windows and Unix, Waiting for approval.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 45•25 years ago
|
||
approved by chofmann, fix and check in
Reporter | ||
Comment 46•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Whiteboard: Get a fix, waiting for code review...
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•