The summary says it all. The build is from 7 Nov 99 in the AM.

The summary doesn't say it all. Where does the assertion occur? What does it say? If this is the assertion in the file transport, we think it's due to canceling the request, and is harmless.

kberk, for assertion failures, it's helpful to paste in the stack trace and condition which are asserting. Right now, the only assertion failure I see when quitting is in the file transport as warren says, so I'll reassign to him.

If this is the same assert Warren, waterson and I were talking about in the mailnews group last week, then we are asserting in the file channel when we are trying to load the animated throbber gif. (that's the url for the file transport that is asserting).

Actually, I posted a message in the QA newsgroup asking how to do a stack trace. I build mozilla, so I have VC 6. I just need to know how.

Par - can you work with kberk on how to get a stack trace? Thanks. Also, kberk, when reporting bugs, you should also include the build date of the build you are using. Thanks.

Ok, got the info that was requested. The error I get is: Basically I pulled the tree the morning of the Nov 7th, then did a clobber build (which I mentioned). The build number on mozilla.exe is 1999082316. mozille.exe - Application Error The exception Breakpoint A breakpoint has been reached. (0x80000003) occured in application at location 0x77f7629c. Here is the last of the console output: mailbox_message://kberk@postoffice2.bellatlantic.net/Inbox#46730 OpenURL from XUL nsMessenger::SetWindow(): Getting the webShell of interest... nsMessenger::SetWindow(): Got the webShell messagepane. FolderPaneController.IsCommandEnabled FolderPaneController.IsCommandEnabled FolderPaneController.IsCommandEnabled onEvent(blur) ThreadPaneController.isCommandEnabled threadTree = [object XULTreeElement] ThreadPaneController.isCommandEnabled ThreadPaneController.isCommandEnabled ThreadPaneController.isCommandEnabled ThreadPaneController.isCommandEnabled threadTree = [object XULTreeElement] Document: Done (1.382 secs) OnUnload from XUL Clean up ... # of builders: 1 # of builders: 9 I don't have unix, so this is the best I know how to do. I have been watching and entering bugzilla bugs most of the year. I have seen stack traces in some bugs, and they appeared to contain lots of detail. I was hoping I could help out in that way on this NT machine I am using, but the bug-writing-guidlines just say to give the Dr Watson crash message.

*** Bug 18570 has been marked as a duplicate of this bug. ***

Since bug 18750 was marked a duplicate of this, I'm raising the severity to blocker. I cannot check any table code into the tree until the viewer can cycle through regression test pages as it was doing 2 days ago. I disabled the throbber's aninmated gifs but it made no difference.

Chris, I don't understand why this is a big deal (blocker) for you. It's just an assertion. Just continue.

I checked in the latest stuff Rick and I came up with. However, we still see serious problems: imap spins in CreateNewLineFromSocket, eating all the cpu I see a hack in CreateNewLineFromSocket too that says it should be removed after 11/5/99 imap threads never exit (one per mailbox), sitting in ImapThreadMainLoop (probably want to use a thread pool or something) sometimes the entire process deadlocks in Windows system code (not an nspr thread/monitor/lock deadlock) -- seems to happen sometime when pulling down a mailbox or perhaps when opening another mailbox before the first one has finished. I'll send the bug back to you Scott. Maybe you want to open up new bugs for these issues. Warren

This is related to bug 16814 (fixed).

works for me

Using a debug build from 12/10/99 looks okay.