86645 - M0.9.1 crashes at the 2nd "Default Plugin" window call

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Theo Jakobus]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; OpenVMS 0 Digital_Personal_WorkStation_; en-US;
rv:0.9.1) Gecko/20010606
BuildID:    2001060807

After entering the page http://www.investars.com the window "Default plugin"
appears which informs that the plugin for application/x-shockwave-flash isn't
available. I selected "CANCEL" and the page "Investment Bank Rankings". After
this page showed up I selected "Home" then Mozilla crashes.

Reproducible: Always
Steps to Reproduce:
1. www.investars.com
2. www.investars.com/analystranking.asp
3. www.investars.com/home.asp

Actual Results:  Mozilla crashes

I start Mozilla from a terminal window, after crashing the output is:
Document http://www.investars.com/analystranking.asp loaded successfully
Document http://www.investars.com/home.asp loaded successfully
Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
  serial 115 error_code 9 request_code 62 minor_code 0
%CXXL-F-TERMINATE, terminate() or unexpected() called
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 VMS_SYSLIB                                 0 000000000003150C 000000000011550C
 VMS_SYSLIB                                 0 00000000000335BC 00000000001175BC
----- above condition handler called with exception 004081A4:
%CMA-F-EXIT_THREAD, current thread has been requested to exit
----- end of exception message
                                            0 FFFFFFFF80083C3C FFFFFFFF80083C3C
 PTHREAD$RTL                                0 0000000000021334 000000007BBE3334
 PTHREAD$RTL                                0 000000000002E7D8 000000007BBF07D8
 PTHREAD$RTL                                0 0000000000045C9C 000000007BC07C9C
                                            0 FFFFFFFF800EC254 FFFFFFFF800EC254
                                            0 FFFFFFFF841B46FC FFFFFFFF841B46FC
                                            0 FFFFFFFF809FE3C8 FFFFFFFF809FE3C8
                                            0 FFFFFFFF809FE414 FFFFFFFF809FE414
$

Comment 1

[shrirang khanzode]

keywd: qawanted ; I do nt have open vms to check this.

Comment 2

[av (gone)]

The error code looks similar to what serge has been looking at recently. Serge, 
could it be that your fix missed OpenVMS build somehow?

Comment 3

[serge (gone)]

Yes, something wrong is going on with OpenVMS R11R5 XSync call :(
see the tail of  bug76505, I do not have  OpenVMS around,  I cannot debug it.
nevertheless after we'll remove default plugin bug83754 this problem will go 
away. For now the workaround probably is just delete nullplugin dll from plugins 
directory.
ccing  [e-mail]

Comment 4

[Colin Blake]

If the null plugin is going away, what do we do with this bug report? Mark
it as WONTFIX?

Comment 5

[av (gone)]

There is a discussion on removing the default plugin as a whole. Making 
dependency for now.

Comment 6

[Keyser Sose]

Marking NEW.

Comment 7

[Colin Blake]

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

Comment 8

[Colin Blake]

Here's some more info on the baddrawable that's still happening on OpenVMS.
The problem only happens if I DO NOT dismiss the "default plugin" box. Then
when I either reload the page or go away and then come back to the page,
there is a high chance that I will get the baddrawable error.

Now here's the part that was clouding the issue. Quite often the "default
plugin" box will appear, but then immediately the main Mozilla window will
be brought to the front causing the "default plugin" window to "disappear".

Once I realised that the "default plugin" window was hiding behind the main
Mozilla window, I found that if I always dismiss the "default plugin" window
(by clicking on CANCEL since OpenVMS doesn't have Java yet), then I can't 
get the baddrawable error to reproduce. Unfortunately I can not reproduce
this on UNIX.

There is something else though. And this does reproduce on UNIX. Go to a page
that causes the "default plugin" window to appear (such as 
http://www.eifl.org.uk when you have Java enabled but you don't have a 
Java plugin). Don't click on OK or CANCEL, just hit reload. Now the "default
plugin" box has gone. Reload again and the box will re-appear. Repeated reloads
will toggle the "default plugin" box on and off. Is this expected?

Comment 9

[Colin Blake]

Homing in some more on what I said above:

The BADDRAWABLE only happens if I DO NOT dismiss the "default plugin" box.
Then if I go to another page and then click BACK, I get the BADDRAWABLE. 

Its like the dialog box (the "default plugin" box) has been orphaned.

Should any open dialog boxes be dismissed when the user destroys the page
to which they belong?

Does any of this make sense to anyone???

Comment 10

[Colin Blake]

Theo, I'm 99% sure that all the BADDRAWABLE errors are a result of the 
nullplugin code misbehaving. Most of the null plugin dialogs boxes
in my experience are for Java applets, and you can prevent these from
even appearing by disabling Java in the preferences (prefs->advanced).
I've done this and I've found M0.9.2 to be MUCH more stable. Its not leaking
as much memory either.

Comment 11

[av (gone)]

The nullplugin has no specific target on java applets. It just displays a box 
saying that a plugin which would play on the specific page is missing, Java 
being only one among others. See serge's comment on 2001-06-19 12:26 for 
possible workaround. The fact that you see much of improvement after disabling 
Java must be a different issue.

Comment 12

[Theo Jakobus]

I started to install OpenVMS V7.3 on my workstation in parallel to OpenVMS
V7.2-1 the new version includes DECwindows Motif 1.2-6 (til now I'm using 1.2-5
I don't know anything about the enhancements) and
Java(TM) 2 Runtime Environment, Standard Edition
Classic VM (build 1.3.0-1, 04/12/2001-12:42, native threads, jit)
I guess I'm able to test Mozilla under the new configuration next week.

Comment 13

[Colin Blake]

Note that even with the installation of Java 1.3.0-1, you still don't get
Java support in Mozilla. Java 1.3.0-1 on OpenVMS does NOT include OJI, and
that's what we need.

Comment 14

[Colin Blake]

> The nullplugin has no specific target on java applets. 

OK, well maybe the problem is caused by the fact that we want to display
the null plugin box but its already displayed. I see in the code that we 
detect that situation and don't create a second dialog.

I'm going to have to try harder to reproduce this on Linux.

Comment 15

[av (gone)]

That used to be a problem, and we took some special precautious measures to 
avoid displaying the dialog more than once on Windows for sure, and I beleive 
serge did it on Unix side.

Comment 16

[Colin Blake]

I found the problem. In destroyPixmap, we don't clear nullPluginGdkPixmap, and
so next time we create the null plugin we think we already have the pixmap and
so don't create a new one. This is what leads to the "BadDrawable (invalid
Pixmap or Window parameter)" error. 

I guess it depends upon how long it takes the memory for the pixmap to get
recycled whether or not the error is detected.

I'll attach a patch next. With this patch, I no longer crash.

Want me to check it in?

Comment 17

[Colin Blake]

Attachment: Patch to fix BadDrawable (invalid Pixmap) problem

Comment 18

[serge (gone)]

colin, you are right, gdk_pixmap_unref() calls XFreePixmap if ref_count == 0 
and the next access to nullPluginGdkPixmap should fail,
but it does not crash on linux, the platform I've tested this code:(
The reason I used static declarator for nullPluginGdkPixmap was the performance, 
of course. I tried to call  gdk_pixmap_create_from_xpm_d() just ones, but I've 
messed up with gdk_pixmap_unref() call:(
Maybe it valid do not call gdk_pixmap_unref() at all, because we are using only 
one pixmap instance during whole life of the client. Could you try comment out 
this call and see how it'll work? Thanks.

Comment 19

[Colin Blake]

Removing the call to gdk_pixmap_unref also fixed the problem. That doesn't
leave much in destroyPixmap now!

Who is going to fix this? Now I finally know what it is, I don't want it to
slip through the cracks. I can sumbit a patch if someone will review/approve.

Comment 20

[serge (gone)]

Good finding, thanks Colin. Now I understand the crash in bug 76505 on linux, 
but I don't get it how XSync() after XtUnregisterDrawable() fixes that crash at 
least linux & hpux11 bits, I've tested on. Anyway, without gdk_pixmap_unref() 
which actually calls XFreePixmap(), it looks like we can throw away XSync(), and 
all work just fine. The patch is following.

Comment 21

[serge (gone)]

Attachment: the patch w/o XSync

Comment 22

[Colin Blake]

With the XSync call removed (and the pixmap not deleted), I still crap out
with a BadDrawable. So the XSync call IS needed.

Comment 23

[serge (gone)]

well, in this case we have to leave gtkxtbin.c as it is now.

Comment 24

[Colin Blake]

Yep, I can live with the XSync call :-)

Mozilla is so stable with the pixmap fix. I was up to almost 200 sites loaded
with Chris Hofmann's browser buster before I stopped it to try out the new
patch. Previously I could only get to about 50-60 max. Theo, you're gonna love
0.9.3 :-)

Comment 25

[serge (gone)]

Attachment: corrected patch

Comment 26

[Theo Jakobus]

Colin I'm impressed by your engagement !!!

Thanks

Comment 27

[Christopher Blizzard (:blizzard)]

sr=blizzard, a=blizzard on behalf of drivers for 0.9.3

Comment 28

[av (gone)]

serge's patch -- serge's bug. If you don't mind.

Comment 29

[serge (gone)]

Checking in npshell.c;
/cvsroot/mozilla/modules/plugin/default/unix/npshell.c,v  <--  npshell.c
new revision: 1.13; previous revision: 1.12
done
Checking in nullplugin.c;
/cvsroot/mozilla/modules/plugin/default/unix/nullplugin.c,v  <--  nullplugin.c
new revision: 1.8; previous revision: 1.7
done
---
FIXED

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Did this patch get checked in to the new plugin directory structure as well? 
(Weren't the RCS files copied already?)

Comment 31

[serge (gone)]

Checking in npshell.c;
/cvsroot/mozilla/modules/plugin/samples/default/unix/npshell.c,v  <--  npshell.c
new revision: 1.13; previous revision: 1.12
done
Checking in nullplugin.c;
/cvsroot/mozilla/modules/plugin/samples/default/unix/nullplugin.c,v  <-- 
nullplugin.c
new revision: 1.8; previous revision: 1.7
done

Comment 32

[Theo Jakobus]

Version 0.9.3 is ok.