Description Grant Gayed 2010-05-27 15:28:20 EDT

Created attachment 170249 [details]
dump

(taken from bug 207206)
"
I have been consistently seeing similar crash on RedHat Enterprise Linux 4.0
AS. I am attaching the jvm crash log.

Trying to figure out why this could be happening, I built a debug build of
xulrunner and attached gdb to it to see the stack trace. Here is what it looks
like. It is consistently the same:

#0  0x00c24dfe in g_type_check_instance_cast ()
   from /usr/lib/libgobject-2.0.so.0
#1  0x9e950aea in nsWindow::NativeShow (this=0x8f67398, aAction=0)
    at /home/fanfare/mozilla/widget/src/gtk2/nsWindow.cpp:2836
#2  0x9e94ac15 in nsWindow::Destroy (this=0x8f67398)
    at /home/fanfare/mozilla/widget/src/gtk2/nsWindow.cpp:396
#3  0x9e94a664 in nsWindow::~nsWindow$base (this=0x8f67398)
    at /home/fanfare/mozilla/widget/src/gtk2/nsWindow.cpp:328
#4  0x9e9543a9 in nsChildWindow::~nsChildWindow$delete (this=0x8f67398)
    at /home/fanfare/mozilla/widget/src/gtk2/nsWindow.cpp:4533
#5  0x9e96610b in nsBaseWidget::Release (this=0x8f67398)
    at /home/fanfare/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp:102
#6  0x9e94aa35 in nsWindow::Release (this=0x8f67398)
    at /home/fanfare/mozilla/widget/src/gtk2/nsWindow.cpp:87
#7  0x9df7190e in nsCOMPtr<nsIWidget>::~nsCOMPtr (this=0x8ed6f58)
    at ../../../dist/include/xpcom/nsCOMPtr.h:583
#8  0x9e6b132c in nsWebBrowser::~nsWebBrowser$delete (this=0x8ed6ef8)
    at /home/fanfare/mozilla/embedding/browser/webBrowser/nsWebBrowser.cpp:127
#9  0x9e6b1763 in nsWebBrowser::Release (this=0x8ed6ef8)
    at /home/fanfare/mozilla/embedding/browser/webBrowser/nsWebBrowser.cpp:174
#10 0x9dc0bdc1 in HandleProxyReleaseEvent (self=0x9009c98)
    at /home/fanfare/mozilla/xpcom/proxy/src/nsProxyRelease.cpp:7
#11 0x9dbf990a in PL_HandleEvent (self=0x9009c98)
---Type <return> to continue, or q <return> to quit---
    at /home/fanfare/mozilla/xpcom/threads/plevent.c:688
#12 0x9dbf97ab in PL_ProcessPendingEvents (self=0x8e23c78)
    at /home/fanfare/mozilla/xpcom/threads/plevent.c:623
#13 0x9dbfce16 in nsEventQueueImpl::ProcessPendingEvents (this=0x8e23d08)
    at /home/fanfare/mozilla/xpcom/threads/nsEventQueue.cpp:448
#14 0x9e9561b4 in event_processor_callback (source=0x8e251c8,
    condition=G_IO_IN, data=0x8e23d08)
    at /home/fanfare/mozilla/widget/src/gtk2/nsAppShell.cpp:67
#15 0x00a4c907 in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#16 0x00a2874b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#17 0x00a2a1d2 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#18 0x00a2a6b8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#19 0x02f1c827 in
Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1itera tion ()
   from
/home/fanfare/.iTestConfiguration_3.3/org.eclipse.osgi/bundles/154/1/.cp
/libswt-pi-gtk-3448.so
#20 0x0118bfa6 in ?? ()
#21 0x083924f4 in ?? ()
#22 0xbfe4bee8 in ?? ()
#23 0x00000000 in ?? ()
(gdb)


This happens when a window is being closed. It seems like the JavaXPCOM code is
trying to release a window  object that has already been released. 

It seems to appear primarily when a chrome window is launched, e.g. the window
that asks the user to accept the HTTP certificate. 

It does not happen all the time, but intermittently, which makes me think that
there is some sort of race condition when disposing the window object. 

I would also like to bring it up again that the original fix caused a memory
leak for applications using the getWebBrowser method to access the XPCOM
object. 

FYI, the xulrunner used to do the debug build was mozilla branch
FIREFOX_2_0_0_16_RELEASE. The debug build i had was not stripped, so it has all
the file names and line numbers. 

It would be really cool, if someone takes a look at it. Please let me know if I
can help with anything.
"