Closed Bug 18201 Opened 20 years ago Closed 20 years ago

[Closing Messenger causes Mozilla to assert.

Categories

(MailNews Core :: Backend, defect, P3, blocker)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: kberk.spamaway, Assigned: mscott)

References

Details

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.
Assignee: phil → warren
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.
Summary: Closing Messanger causes Mozilla to assert. → Closing Messenger causes Mozilla to assert.
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.
Target Milestone: M12
*** Bug 18570 has been marked as a duplicate of this bug. ***
Severity: major → blocker
Summary: Closing Messenger causes Mozilla to assert. → [Closing Messenger causes Mozilla to assert.
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.
Blocks: 18189
Assignee: warren → mscott
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
Blocks: 18951
This is related to bug 16814 (fixed).
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
works for me
QA Contact: lchiang → ppandit
Status: RESOLVED → VERIFIED
Using a debug build from 12/10/99 looks okay.
No longer blocks: 18951
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.