15308 - [CRASH][PP] File|Close causes app to crash

Status: VERIFIED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Claudius Gayle]

*SUMMARY
	Selecting File|Close in any case except from the main browser window
when there is only the one window causes a crash.

*To Repro
	Launch Seamonkey. Open a new Navigator window or the Bookmarks
window or any other window. Select File|Close. Sometimes you have to wait
a few seconds or click a menu, usually it just crashes right away.

the following line is printed to the console:
Gtk-WARNING **:  invalid cast from (NULL) pointer to 'GtkWidget'

*Build Info
	This bug was tested on all platforms and reproduced on Linux ONLY with
the 1999093013.

stack trace coming soon

Comment 1

[Paul MacQuiddy]

I filed a talkback report, linked to above, but it doesn't have line#'s just the
.dll that it crashed in, which looked to be raptorhtml.dll. Who should own this
bug?

Comment 2

[phillip]

Attachment: stack trace on redhat 6 (gdb)

Comment 3

[chris hofmann]

Think we are waiting on a fix from ramiro,dp,dveditz on this

Program received signal SIGSEGV, Segmentation fault.
0x1 in ?? ()
(gdb) bt
#0  0x1 in ?? ()
#1  0x40b782f7 in NSUnregisterSelf ()
#2  0x40479d86 in nsWidget::OnButtonPressSignal ()
#3  0x4047a2d7 in nsWidget::ButtonPressSignal ()
#4  0x405e0229 in gtk_marshal_BOOL__POINTER ()
#5  0x405a565d in gtk_handlers_run ()
#6  0x405a4ab2 in gtk_signal_real_emit ()
#7  0x405a2c05 in gtk_signal_emit ()
#8  0x405d79d8 in gtk_widget_event ()
#9  0x40578b22 in gtk_propagate_event ()
#10 0x40577d7a in gtk_main_do_event ()
#11 0x406200fb in gdk_event_dispatch ()
#12 0x4064da86 in g_main_dispatch ()
#13 0x4064e041 in g_main_iterate ()
#14 0x4064e1e1 in g_main_run ()
#15 0x405777a9 in gtk_main ()
#16 0x4046a515 in nsAppShell::Run ()
#17 0x40370c92 in nsAppShellService::Run ()
#18 0x804a7ae in strcpy ()
#19 0x804a987 in strcpy ()
#20 0x401fdcb3 in __libc_start_main (main=0x804a894 <strcpy+4160>, argc=1,
argv=0xbffff944,
    init=0x80494d4 <_init>, fini=0x804cc78 <_fini>, rtld_fini=0x4000a350
<_dl_fini>, stack_end=0xbffff93c)
    at ../sysdeps/generic/libc-start.c:78

Comment 4

[Stuart Parmenter]

this is probably due to someone partially destroying a widget without really
destroying it.  i'm working on cleaning up the widget destruction process which
will probably make this not happen.

Comment 5

[Suresh Duddi (gone)]

Something is *really* wierd about the trace. NSUnregisterSelf() cannot ever be
called from nsWidget::<whatever>

Either the stack is corrup or we have a really wayward pointer. And hofmann,
there isnt anymore fixes for shutdown that ramiro or me are doing.

Comment 6

[scalkins]

In Build 1999/10/01 09am  (M11), this also occurs for Windows envmt. On Win you
will crash. You cannot F5 through this crash.

Comment 7

[Chris McAfee]

I can tolerate crashing on exit for m10.

Comment 8

[chris hofmann]

we can watch for this in m10 talkback data to see
if there is a pattern in the random crashes...

Comment 9

[Claudius Gayle]

this not crash on exit. this is File|Close not File|Exit.

this happens every_single_time you select File|Close from
any thing other than the main browser window. This means
other browser windows and all XPApps. The sure fire way to
repro is to select File|Close and then click on File on the main
window once more.
I've reproduced this on 3 different Linux boxes myself and heard
of 1 other.

Comment 10

[Syd Logan]

Couldn't duplicate this, no matter how hard I tried (editor, wallet, a second
browser, mailnews, commercial tree and mozilla). Worksforme.

Comment 11

[Claudius Gayle]

this is why I hate the WFM resolution.
marking VERIFIED WFM.

Comment 12

[Peter Trudelle]

Claudius, you didn't verify this while you could still reproduce it, did you?

Comment 13

[Claudius Gayle]

Nope. What _meant_ to say in place of the bitter comments was...

I was unable to reproduce this in current builds (now 2000011212)
and therefore am forced to concur with the resolution of WFM, even
though it is my belief that this was simply fixed over time, I am
therefore marking it verified.

Comment 14

[Peter Trudelle]

Oh. That's not nearly as bitter as when the engineer marks it wfm because he
can't identify a checkin specifically intended to fix it.