dunno if bug 67879 fix is causing this. Today's build on linux(0418) crashes on any page where the defaul plugin tries to come up.

Shrirang, does this still happen? There was a checkin in the Linux default plugin yesterday.

yes, Andrei, this is happening except for the ' http://webcamnow.com ' url. Earlier, i was unable to crash the browser on java.sun.com but it used to happen on the webcamnow site. Now , it's the exact reverse...al lother sites crash while bringing the default plugin and the webcamnow site does not crash. Pls let me know if i am not clear. Thx

This is the error in the console when the browser closes : Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 15 error_code 9 request_code 55 minor_code 0

I understand, I confused it with something else. Reassigning to serge.

Looks like a 0.9 must.

Adding ``crash'' keyword.

The serial number differs, the rest is always error_code 9 request_code 55 minor_code 0

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

I'm investigating it ...

Status Whiteboard --> 0.9

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

bug 40931 was/is a similar crash, but it wasn't the nullplugin casuing it at the time.

I just tried chofmann's browser buster, and mozilla died on one of the top 100 sites because of this very bug.

Here's another instance of what looks to me like the same bug. Discovered on OpenVMS but reproduced on Linux. 2001041908 build on RedHat 7.0 Go to www.usatoday.com Click on the "auto review video" link in the top right corner ** A small window appears and then Mozilla crashes. Attached is my console log. ** in case this link has gone, the URL was the javascript:OpenVideo one you can see in the "Error loading URL" message below. [root@linux m09-pre]# ./mozilla /run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/home/mozilla/m09-pre LD_LIBRARY_PATH=/home/mozilla/m09-pre LIBRARY_PATH=/home/mozilla/m09-pre:/home/mozilla/m09-pre/components SHLIB_PATH=/home/mozilla/m09-pre LIBPATH=/home/mozilla/m09-pre ADDON_PATH=/home/mozilla/m09-pre MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Registering plugin 0 for: "*","All types",".*" Document http://www.mozilla.org/ loaded successfully JavaScript strict warning: http://www.usatoday.com/_common/_scripts/sniffer.js line 219: test for equality (==) mistyped as assignment (=)? JavaScript error: http://www.usatoday.com/_common/_scripts/sniffer.js line 126: arrUA[1] has no properties Document http://www.usatoday.com/ loaded successfully Error loading URL javascript:OpenVideo(' http://play.rbn.com/?url=usat/usat/g2demand/010419_car.smil&proto=rtsp') : 2152924149 JavaScript error: http://www.usatoday.com/video/mplay5v1.htm line 201: PlayerObj.SetSource is not a function Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 17 error_code 9 request_code 55 minor_code 0 [root@linux m09-pre]#

In case this one can't be fixed in time for 0.9 we should at least disable Java by default. If we don't, every site with java will crash for the people who don't have java installed.

It looks like I can easily eliminate gdk_x_error() by removing all X11/Xt code from nullplugin, and probably I'll do so if I'll not find any other appropriate solution... But the strange thing is even alone XDefineCursor() call causes the _XError() with stack trace looking like: #0 0x409632c6 in gdk_x_error () from /usr/lib/libgdk-1.2.so.0 #1 0x409ffecd in _XError () from /usr/X11R6/lib/libX11.so.6 #2 0x409fd291 in _XEventsQueued () from /usr/X11R6/lib/libX11.so.6 #3 0x409f0f2c in XEventsQueued () from /usr/X11R6/lib/libX11.so.6 #4 0x416a4b4d in XtAppPending () from /usr/X11R6/lib/libXt.so.6 #5 0x40f68a2f in xt_event_dispatch(source_data=0x887efc8,current_time=0xbfffefc0, user_data=0x85cac70) at gtkxtbin.c:145 #6 0x4099f987 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #7 0x409a0001 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #8 0x409a01cc in g_main_run () from /usr/lib/libglib-1.2.so.0 #9 0x408b9e57 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #10 0x407d04c9 in ?? ()from /u/serge/prj/ns6/trunk/linux/mozilla/dist/bin/components/libwidget_gtk.so #11 0x4070f46f in ?? ()from /u/serge/prj/ns6/trunk/linux/mozilla/dist/bin/components/libnsappshell.so #12 0x8053427 in main1 (argc=1, argv=0xbffff324, nativeApp=0x0) at nsAppRunner.cpp:1021 #13 0x805415b in main (argc=1, argv=0xbffff324) at nsAppRunner.cpp:1316

That's probably the call that's flushing the X buffer. Run with --sync and I think that it will keep the connection flushed after every request. The only problem with that is that the Xt code is on a seperate connection so it might not work with --sync since it's the gtk connection to the X server. Removing the X11/Xt code from the null plugin is probably the wrong solution. It might be as simple as adding an XSync() in the right place. I think that we've run into this before...

I reported bug 76734 which also seems related to this one. A different stack trace and two different URLs (www.electronicnews.com and www.hardocp.com) are referred to there. Also, mozilla seems to have started crashing very recently on these sites.

Thanks Chris, I was playing with XSync() for a while... it seems to me the next patch is doing the right thing ======= RCS file: /cvsroot/mozilla/widget/src/gtkxtbin/gtkxtbin.c,v retrieving revision 1.6 diff -u -r1.6 gtkxtbin.c --- gtkxtbin.c 2001/01/04 22:13:00 1.6 +++ gtkxtbin.c 2001/04/20 21:20:35 @@ -420,6 +420,10 @@ GDK_WINDOW_XWINDOW(GTK_WIDGET(object)->window))); #endif + /* flush the queue before we returning origin top_widget->core.window + or we can get X error since the window is gone */ + XSync(xtbin->xtdisplay, False); + xtbin->xtwidget->core.window = GPOINTER_TO_UINT(gtk_object_get_data(object, "oldwindow")); XtUnrealizeWidget(xtbin->xtwidget); ----- Could you please take a look and sr= if you agree?

Patch seems to fix crash, tested with several plugin pages. Crash seems to happen when plugin area is reflowed or when plugin is offscreen. Easy way to reproduse crash is to resize browser window really small. I wonder is this real fix or does this only hide real problem elsewhere?

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

Tomi Leppikangas, I resized mozilla really small (plugin downloader was larger than the mozilla window) and it still didn't crash.

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

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

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

Using buildid 2001042209, www.hardocp.com and www.electronicnews.com still crash in exactly the same manner as described in 76734. FYI, I am now running Mandrake Linux 8.0 (previously, I saw the crash on Mandrake 7.2) with kernel 2.4.3-20mdk, glibc 2.2.2-4mdk, libgtk-1.2.so.0.9.1, XFree86 4.0.3, window manager icewm 1.0.7-4mdk. According to free, I had > 180M free memory with no swap in use.

Will this patch go in, or are you working on improving it? It has worked fine here since I applied it, and it has saved me from tons of crashes.

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

anedah-9@sm.luth.se: the patch will go in as soon as some special requirements to check in against a closed tree are met.

I think we should remove xt_event_poll_fd from the main glib pool, if there is no active plugins, other way we are wasting the time on calls of xt_event_prepare http://lxr.mozilla.org/seamonkey/source/widget/src/gtkxtbin/gtkxtbin.c#59 xt_event_check http://lxr.mozilla.org/seamonkey/source/widget/src/gtkxtbin/gtkxtbin.c#80 even more: these calls can trigger gdk_x_error() handler in some cases. I'm attaching the patch for this.

Where is the XSync() in that patch?

Missed it. r/sr/a=blizzard for 0.9 for the XSync() only patch. It's low risk, makes sense and seems to fix the problem. Please open another bug for the optimization.

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

Please get this in! It's killing me.

cheched in /cvsroot/mozilla/widget/src/gtkxtbin/gtkxtbin.c,v <-- gtkxtbin.c new revision: 1.7; previous revision: 1.6 -- resolved as FIXED

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

verified fixed on linux commercial build 2001-04-25-05-trunk

OpenVMS using X11R5 and GTK 1.2-8. The new XSync call is causing a problem for me. If I go to http://www.eifl.org.uk/ it loads OK, but if I then hit reload I get: Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 58 error_code 9 request_code 62 minor_code 0 Like I said, this happens when I call XSync.

I don't have any access to OpenVMS, I don't know how to debug it:( colin@theblakes.com are you saying without XSync everything works fine for you? Did you try to apply the second patch, which cleans up xt event poll?

> colin@theblakes.com are you saying without XSync everything works fine > for you? No. Without the XSync I get the crash other people were getting. With the XSync I get a different crash (and not always). > Did you try to apply the second patch, which cleans up xt event poll? That's what I was about to try next.

The second patch made no difference. I still get the crash. I can usually reproduce it by going to http://www.eifl.org.uk/ which causes the default plugin box to come up. I click on CANCEL and the box goes away. But then when I click on RELOAD, it starts to reload and then KA-BOOM. Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 58 error_code 9 request_code 62 minor_code 0 I can't reproduce this on Linux unfortunately. The only bit of stack dump I can get is this: LIBGDK GDK gdk_x_error some system stuff LIBGTKXTBIN GTKXTBIN gtk_xtbin_shutdown LIBGTK GTKOBJECT gtk_object_destroy LIBGKPLUGIN NS4XPLUGININSTANCE SetWindow LIBGKLAYOUT NSOBJECTFRAME DidReflow Does this mean anything to anyone? Colin.

What's line number for LIBGTKXTBIN GTKXTBIN gtk_xtbin_shutdown ? Could you try the next patch? =========================================================== RCS file: /cvsroot/mozilla/widget/src/gtkxtbin/gtkxtbin.c,v retrieving revision 1.7 diff -u -r1.7 gtkxtbin.c --- gtkxtbin.c 2001/04/24 20:11:46 1.7 +++ gtkxtbin.c 2001/05/11 20:30:29 @@ -418,6 +418,7 @@ _XtUnregisterWindow(GDK_WINDOW_XWINDOW(GTK_WIDGET(object)->window), XtWindowToWidget(xtbin->xtdisplay, GDK_WINDOW_XWINDOW(GTK_WIDGET(object)->window))); + xtbin->xtwidget->core.window = 0; #endif

Tried the latest patch (xtbin->xtwidget->core.window = 0). It might have made things a little better, but it hasn't fixed the problem. Without this patch if I went to www.eifl.org.uk, waited for it to load (its a slow page), it would always crash the FIRST time I hit RELOAD. With this patch, I can sometimes reload several times before it will eventually crash. The stack trace is always the same (as posted above). I didn't post the line numbers in the stack trace because they don't match real line numbers (its a long story, to do with me having to build within a POSIX sub-system). But I put print statements immediately before and after the XSync call in gtk_xtbin_shutdown and sure enough, its failing while in the XSync call. The last patch was only patching the non-R6 code (after the call to _XtUnregisterWindow), so I guess you're aware that OpenVMS is only X11R5. Also be aware that OpenVMS doesn't have OJI support yet so each time I visit www.eifl.org.uk I get the "default plugin" box pop up, to which I have to kit CANCEL (in case that makes a difference).