Closed Bug 76505 Opened 23 years ago Closed 23 years ago

browser crashes as soon as default plugin download dialog comes up

Categories

(Core Graveyard :: Plug-ins, defect, P1)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: shrir, Assigned: srgchrpv)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: mozilla 0.9- have r/sr/a - ready for checkin)

Attachments

(1 file)

second patch to remove xt_event_poll_fd from the main glib pool; it has XSync() in
2.76 KB, patch
Details | Diff | Splinter Review 
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.
Assignee: av → serge
Looks like a 0.9 must.
Priority: -- → P1
Target Milestone: --- → mozilla0.9
Adding ``crash'' keyword.
Keywords: crash
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
Whiteboard: mozilla 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. ***
Blocks: 76921
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.
Blocks: 71163
Whiteboard: mozilla 0.9 → mozilla 0.9- have r/sr/a - ready for checkin
*** 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
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Blocks: 77389
*** Bug 77405 has been marked as a duplicate of this bug. ***
verified fixed on linux commercial build 2001-04-25-05-trunk
Status: RESOLVED → VERIFIED
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).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: