I've seen this most in the commercial tree, mistly with IM. But, I've also seen with mail news, and at least once or twice just closing the browser. Start mozilla (commercial), bring up IM standalone, go to file menu and select close. Or, do the same with mail news. Stack trace: #0 0x402f4112 in ?? () from /lib/libc.so.6 #1 0x4080d6ec in ?? () from /usr/local/lib/libglib-1.2.so.0 #2 0x4068dbad in nsWidget::~nsWidget (this=0x82c25a0, __in_chrg=3) at nsWidget.cpp:284 #3 0x4069495c in nsWindow::~nsWindow (this=0x82c25a0, __in_chrg=3) at nsWindow.cpp:168 #4 0x4068dcb3 in nsWidget::Release (this=0x82c25a0) at nsWidget.cpp:296 #5 0x4054b051 in nsWebShellWindow::Close (this=0x82011b8) at nsWebShellWindow.cpp:440 #6 0x4042ebad in GlobalWindowImpl::Close (this=0x82b9d20) at nsGlobalWindow.cpp:1348 #7 0x4042ec3f in GlobalWindowImpl::CloseWindow (aWindow=0x82b9d24) at nsGlobalWindow.cpp:1359 #8 0x4041cceb in nsJSContext::ScriptEvaluated (this=0x82ba6e0) at nsJSEnvironment.cpp:741 #9 0x4041c3cd in nsJSContext::CallEventHandler (this=0x82ba6e0, aTarget=0x41a45688, aHandler=0x41a45690, argc=1, argv=0xbfffed7c, aBoolResult=0xbfffeccc) at nsJSEnvironment.cpp:553 #10 0x40459ae9 in nsJSEventListener::HandleEvent (this=0x8388078, aEvent=0x84fd7fc) at nsJSEventListener.cpp:128 #11 0x40f5e6cd in nsEventListenerManager::HandleEventSubType (this=0x8388038, aListenerStruct=0x83880a8, aDOMEvent=0x84fd7fc, aSubType=8) at nsEventListenerManager.cpp:651 #12 0x40f6052a in nsEventListenerManager::HandleEvent (this=0x8388038, aPresContext=0x41796628, aEvent=0xbffff298, aDOMEvent=0xbffff238, aFlags=7, aEventStatus=0xbffff2d8) at nsEventListenerManager.cpp:1410 #13 0x409fa1ac in ?? () from /opt/raptor/ns/dist/bin/components/librdf.so #14 0x41180468 in nsMenuFrame::Execute (this=0x83a78cc) at nsMenuFrame.cpp:1232 #15 0x4117c189 in nsMenuFrame::HandleEvent (this=0x83a78cc, aPresContext=0x41796628, aEvent=0xbffff6c8, aEventStatus=0xbffff5c4) at nsMenuFrame.cpp:282 #16 0x40fb1a5c in PresShell::HandleEvent (this=0x41ab2088, aView=0x847e608, aEvent=0xbffff6c8, aEventStatus=0xbffff5c4) at nsPresShell.cpp:2649 #17 0x414d7659 in nsView::HandleEvent (this=0x847e608, event=0xbffff6c8, aEventFlags=8, aStatus=0xbffff5c4, aHandled=@0xbffff568) at nsView.cpp:840 #18 0x414d75ed in nsView::HandleEvent (this=0x4179d018, event=0xbffff6c8, aEventFlags=28, aStatus=0xbffff5c4, aHandled=@0xbffff568) at nsView.cpp:824 #19 0x414e3483 in nsViewManager::DispatchEvent (this=0x415cd260, aEvent=0xbffff6c8, aStatus=0xbffff5c4) at nsViewManager.cpp:1676 #20 0x414d5724 in HandleEvent (aEvent=0xbffff6c8) at nsView.cpp:68 #21 0x4068fecb in nsWidget::DispatchEvent (this=0x8484180, aEvent=0xbffff6c8, aStatus=@0xbffff660) at nsWidget.cpp:1384 #22 0x4068fafc in nsWidget::DispatchWindowEvent (this=0x8484180, event=0xbffff6c8) at nsWidget.cpp:1275 #23 0x4068ff85 in nsWidget::DispatchMouseEvent (this=0x8484180, aEvent=@0xbffff6c8) at nsWidget.cpp:1411 #24 0x406914ef in nsWidget::OnButtonReleaseSignal (this=0x8484180, aGdkButtonEvent=0x4135a018) at nsWidget.cpp:2054 #25 0x40696075 in nsWindow::HandleGDKEvent (this=0x8484180, event=0x4135a018) at nsWindow.cpp:1092 #26 0x40682a9d in handle_gdk_event (event=0x4135a018, data=0x0) at nsGtkEventHandler.cpp:887 #27 0x407e3382 in ?? () from /usr/local/lib/libgdk-1.2.so.0 #28 0x4080aae3 in ?? () from /usr/local/lib/libglib-1.2.so.0 #29 0x4080b06f in ?? () from /usr/local/lib/libglib-1.2.so.0 #30 0x4080b1f1 in ?? () from /usr/local/lib/libglib-1.2.so.0 #31 0x40745277 in gtk_main () at gtkmain.c:475 #32 0x40678215 in nsAppShell::Run (this=0x80bb630) at nsAppShell.cpp:400 #33 0x40548a21 in nsAppShellService::Run (this=0x80a8c00) at nsAppShellService.cpp:481 #34 0x804bf8d in main1 (argc=1, argv=0xbffffa54) at nsAppRunner.cpp:609 #35 0x804c2d9 in main (argc=1, argv=0xbffffa54) at nsAppRunner.cpp:677 #36 0x402bacb3 in ?? () from /lib/libc.so.6

Putting on the PDT+ radar.

I'll try to reproduce this tomorrow.

I can't reproduce this and I don't see anything in the nsWidget() destructor that might cause this problem. Since it shows up in AIM ( which I don't have ) I need more debugging information before I can track this down. If it's still happening, someone is going to have to proxy for me.

I can reproduce by removing my profile (rm -rf ~/.mozilla), starting mozilla (not the commercial tree), and then filling out the profile stuff, and when the profile wizard is brought down, wee crash. Play around with dialogs, eventually you will see this. No need for a proxy.

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

Really. I've tried that. Works fine for me. No crashes. Prefs dialog, mail windows, wizards, etc. It's not crashing.

Another test case -- tip of the tree build on 1/2/00, crashed dismissing the password dialog in mail news when attempting to log onto IMAP server. Blizzard, what version of Gtk+ are you using? I'm using Gtk 1.2.1, and we are supposed to be supporting Gtk+ 1.2.0 and higher.

Oh, I'm also using 1.2.6, I think.

http://bugzilla.mozilla.org/show_bug.cgi?id=23459 is low-bandwidth dependent bugs. Possible that I see this problem because I have a slow machine and net connection.

Worksforme. Upgrading my machine to RH 6.1 (and GTK 1.2.5) fixed this. Not sure if it was the upgrade or my system was somehow horked, but I can't seem to duplicate.

This kind of scares me. Did you have this running on 6.0 with gtk 1.2.6 or gtk 1.2.5 with the crash?

I was running RH 6.0 with GTK 1.2.1.

I'll have to try that combination here.

Clearing WORKSFORME resolution due to reopen.

Ok, I set up a RH 6.0 box and still can't reproduce this. Worksforme.

spam: QA contact to jrgm (PDT+ resolved to be verified)

If syd and blizzard are comfortable with this WORKSFORME, then I'll rubber-stamp the verify (plus this was during M12). Marking VERIFIED.

Sorry. missed the magic button -- verified.

Please ignore the spam. Changing address.

busted from my reassign

put back to verified ...