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.

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.

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?

correcting platform to all per laurel's 4/30 comments.

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.

Yes, this sounds exactly like 5735. We should probably mark it as a dup.

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 :-)

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.

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.

Thanks John, I'll try out the patch this weekend.

M5, IMO

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.

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.

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.

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.

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.

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?

That most recent stack trace does not look anything like the previous stack trace (withe xpconnect init problem). Is this another bug entirely?

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.

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 ***

Marking verified as duplicate to get off resolved list. When the master bug is fixed I'll double-check this scenario again.