Closed
Bug 5719
Opened 26 years ago
Closed 25 years ago
Selecting inbox messages in sequence quickly crashes.
Categories
(MailNews Core :: Backend, defect, P2)
Tracking
(Not tracked)
M6
People
(Reporter: laurel, Assigned: mscott)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Using 1999042908 on NT 4.0 and Win95
Cannot test on linux due to #5572 crasher
Selecting messages in pop inbox from top to bottom in sequence fairly rapidly
will crash. I put mention of this in bug #5572 comments yesterday, but Scott
MacGregor believes this is a different bug and is taking ownership. Please note
it is easier to crash than it was in 4/27's windows build.
Steps:
1. Remove .msf files.
2. Launch apprunner, go to Messenger.
2. (using POP) display inbox contents. (Please note in my inbox were only a
few text only messages none more than a few sentences long.)
3. Select the first message, then immediately move to the second, then to the
third, etc.
Result: I crash consistently on the 4th message. No problems in displaying
said message generally; it's only when quickly moving down the inbox in
sequence.
Talkback/Full circle tracking ID: D3M57FTC
Update for 4/30 builds: still crashing on Win32 and crashes on Linux, too. On
the Mac it doesn't crash, but when the selection gets ahead of the display you
start seeing xml parsing errors for messages which will display fine if you
reselect and give it time.
Assignee | ||
Comment 2•26 years ago
|
||
Here's the current stack trace I get with this crash:
nsDebug::Assertion(const char * 0x00fc9c48, const char * 0x00fc9c34, const char
* 0x00fc9c08, int 446) line 140 + 13 bytes
NS_CreateContext(nsIScriptGlobalObject * 0x01d96904, nsIScriptContext * *
0x01d192fc) line 446 + 38 bytes
nsWebShell::CreateScriptEnvironment() line 2242 + 20 bytes
nsWebShell::GetScriptGlobalObject(nsWebShell * const 0x01d192dc,
nsIScriptGlobalObject * * 0x0012fd64) line 2270 + 11 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x01d90cb0, void *
0x00e70a86, nsIDeviceContext * 0x01d1bf80, nsIPref * 0x00be1650, const nsRect &
{x=0 y=0 width=1011 height=905}, nsScrollPreference nsScrollPreference_kAuto)
line 314
nsWebShell::Embed(nsWebShell * const 0x01d192d0, nsIContentViewer * 0x01d90cb0,
const char * 0x01d1bbd0, nsISupports * 0x00000000) line 726 + 69 bytes
nsDocumentBindInfo::OnStartBinding(nsDocumentBindInfo * const 0x01d1bc10, nsIURL
* 0x01d1cc10, const char * 0x01d59e20)
The assertion failure is:"xpconnect unable to init jscontext"
cc'ing jband on this in case he has any ideas. The stack trace is pretty far
removed from any of the mailnews code.
Assignee | ||
Comment 3•26 years ago
|
||
This crash with an identical stack trace also occurrs on windows. jband, would
this be an appropriate bug to assign to you or someone over in your group?
Comment 5•26 years ago
|
||
This sounds like a dup of a bug that waterson mentioned to me. (I added him to
the cc list)
mozilla's current behavior is to create and delete JSContexts with reckless
abandon, though it would be perfectly valid to have one per thread.
There is no code to tell xpconnect when JSContexts are being deleted. I
speculate that JS is reusing pointers for previously alloc'd and free'd
JSContexts. xpconnect is failing because it is getting told to initialize itself
on a JSContext that it thinks is already in use.
We can do a quick fix in nsJSEnvironment.cpp to have it fail silently when
xpconnect can not be inited. The real fix is to add the mechanism to xpconnect
to let it know when JSContexts are being deleted and to call that mechanism in
mozilla at the proper places. I plan to do this when M5 is out and the tree
opens.
Does this need to be fixed for M5?
I have no idea how to setup and reproduce this bug. If you want to assign it to
me, fine, just someone please tell me how to reproduce it without whacking my
real mail.
Comment 6•26 years ago
|
||
Yes, this sounds exactly like 5735. We should probably mark it as a dup.
Assignee | ||
Comment 7•26 years ago
|
||
Lisa/Laurel, What do the two of you think? Is this an M5 stopper?
I think this is ok to wait until after M5. I was trying this out on Windows and
you have to be pretty quick on those clicks! I am not fast enough to cause a
crash yet :-)
Assignee | ||
Comment 9•26 years ago
|
||
It's actually not speed related for me. I can view messages pretty slowly in the
debugger and it will crash. But I'll let you make the final call as to whether
it is an M5 stopper or not.
Comment 10•26 years ago
|
||
Hmm, in that case, perhaps we should see the risk(s) associated with a fix in
this area and go from there. Cc: chofmann because this could be a potential M5
bug.
Comment 11•26 years ago
|
||
Assignee | ||
Comment 12•26 years ago
|
||
Thanks John, I'll try out the patch this weekend.
Updated•26 years ago
|
Target Milestone: M5
Comment 13•26 years ago
|
||
M5, IMO
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•26 years ago
|
||
Well, I can't seem to reproduce the crash today although I'm sure it is still
there. It is just harder to trigger. I just iterated through a 250 message Inbox
and didn't crash.
I assume this bug is going to get marked as a duplicate of 5735. The question
is, is its effect on MailNews an M5 stopper?
When Phil marked it as an M5 stopper, it was after I told him it caused me to
crash every 4 or 5 messages or so. But then I just tried it again and was able
to display 250 messages without a problem.
Laurel, is it still easy for you to reproduce? If not, I'd suggest marking it as
a dup and not necessarily holding M5 for the fix.
Assignee | ||
Comment 15•26 years ago
|
||
I should point out that I have not tried things with John's patch because I
haven't been able to consistently reproduce the crash again today. So I couldn't
verify that the patch worked if I tried it out.
Updated•26 years ago
|
Whiteboard: can't reproduce now...
Assignee | ||
Comment 16•26 years ago
|
||
I'm adding Esther to the cc list as Laurel is out today and tomorrow.
The current thinking is to mark this bug as a duplciate of the non m5 stopper
and if this crash becomes really common we can look at taking John's patch on
the branch for M5.
Assignee | ||
Comment 17•26 years ago
|
||
I meant to add (I've been forgetful today) that Esther is going to try
reproducing this bug again today to see if she can find a regular pattern.
Updated•26 years ago
|
Target Milestone: M5 → M6
Comment 18•26 years ago
|
||
moving to m6. let me know if we come up with good test case and a fix
and we may be able to apply tp the branch.
Comment 19•25 years ago
|
||
Stack trace from talkback report:
nsString::SetString
[d:\builds\seamonkey\mozilla\base\src\nsString.cpp, line 844]
nsDocument::GetNodeName
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp, line 1816]
nsWebShell::Embed
[d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 734]
DocumentViewerImpl::Init
[d:\builds\seamonkey\mozilla\webshell\src\nsDocumentViewer.cpp, line 320]
nsWebShell::Embed
[d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 734]
nsDocumentBindInfo::OnStartBinding
[d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 2033]
OnStartBindingProxyEvent::HandleEvent
[d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 506]
StreamListenerProxyEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 472]
PL_HandleEvent
[plevent.c, line 477]
PL_ProcessPendingEvents
[plevent.c, line 438]
_md_EventReceiverProc
[plevent.c, line 803]
USER32.dll + 0x13ed (0x77e713ed)
nsappshell.dll + 0x1563 (0x00e51563)
mainCRTStartup()
KERNEL32.dll + 0x1b304 (0x77f1b304)
----
Laurel - still occurring for you?
Comment 20•25 years ago
|
||
That most recent stack trace does not look anything like the previous stack
trace (withe xpconnect init problem). Is this another bug entirely?
Reporter | ||
Comment 21•25 years ago
|
||
Using the may11th build on Windows, I'm not seeing the original problem anymore.
Tries a few times to reproduce.
will try again and also on other platforms.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Whiteboard: can't reproduce now...
Assignee | ||
Comment 22•25 years ago
|
||
clearing status whiteboard. I still see the crash. And jband, the stack trace is
still the init context problem (i.e. the stack trace I originally posted).
Let's mark this as a dup of waterson's bug assuming it also has an M6 target
fix.
*** This bug has been marked as a duplicate of 5735 ***
Reporter | ||
Comment 23•25 years ago
|
||
Marking verified as duplicate to get off resolved list. When the master bug is
fixed I'll double-check this scenario again.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•