386844 - Crash when running Java Applets [@ XSync - JavaPluginInstance5::SetWindow]

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Bill Gianopoulos [:WG9s]]

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a7pre) Gecko/2007070304 Minefield/3.0a7pre ID:2007070304

The check-in for bug 384845 appears to cause any attempt to use JAVA to crash for me.  If you go to http://sametime.psclistens.com/stconf.nsf/WebTestMeeting?OpenForm

and click on the "Test My Browser" button you get a crash.  I also get crashes trying to log into https://certadmin.entrust.com/ which uses liveconnect.

Unfortunately I am on a 64-bit Linux platform so cannot get anything useful from crash reporter.  I ran with a -g and manged to get this:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4146039408 (LWP 26891)]
0x00ba0596 in XSync () from /usr/lib/libX11.so.6
(gdb) backtrace
#0  0x00ba0596 in XSync () from /usr/lib/libX11.so.6
#1  0xf2b07a1d in JavaPluginInstance5::SetWindow ()
   from /usr/java/jre1.6.0_01/lib/i386/libjavaplugin_nscp.so
#2  0xf2bf7ca7 in CNSAdapter_JavaPlugin::SetWindow ()
   from /usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
#3  0xf7b2ff15 in fstat () from ./libxul.so
#4  0xf7b26670 in fstat () from ./libxul.so
#5  0xf7704a49 in fstat () from ./libxul.so
#6  0xf7705da0 in fstat () from ./libxul.so
#7  0xf77ff0e4 in fstat () from ./libxul.so
#8  0xf7800066 in fstat () from ./libxul.so
#9  0xf7d09c1b in NS_GetComponentManager_P () from ./libxul.so
#10 0xf7cd9777 in JNIEnv_::ThrowNew () from ./libxul.so
#11 0xf7c62254 in JSD_DebuggerOnForUser () from ./libxul.so
#12 0xf7ad61d8 in fstat () from ./libxul.so
#13 0xf75576fc in XRE_main () from ./libxul.so
#14 0x0804891b in ?? ()
#15 0x00000001 in ?? ()
#16 0xffbf5b24 in ?? ()
#17 0x0804cf68 in ?? ()
#18 0x000008f0 in ?? ()
#19 0x468b8eb0 in ?? ()
#20 0xf7f178c0 in ?? () from ./libxul.so
---Type <return> to continue, or q <return> to quit---
#21 0xffbf5a58 in ?? ()
#22 0xffbf5b24 in ?? ()
#23 0x00000001 in ?? ()
#24 0xf7cffa72 in NS_NewLocalFile_P () from ./libxul.so
#25 0x009f2f2c in __libc_start_main () from /lib/libc.so.6
#26 0x080487c1 in ?? ()

Comment 1

[Bill Gianopoulos [:WG9s]]

I should have mentioned this is with:

Java(TM) Plug-in 1.6.0_01-b06

Comment 2

[Bill Gianopoulos [:WG9s]]

I should also have made it clear that although I am running on a 64-bit OS, this crash occurs using the official 32-bit nightly build.

I created a debug build and managed to capture this:

JavaScript strict warning:
http://sametime.psclistens.com/sametime/webattend.js, line 361: assignment to
undeclared variable jsExtDiv
WARNING: failed querying PAC file; trying DIRECT: file
/home/wag/mozilla/trunk/netwerk/base/src/nsProtocolProxyService.cpp, line 855
For application/x-java-vm found plugin
/usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
LoadPlugin() /usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
returned ae04990
WARNING: CreateSecureEnv OK: file
/home/wag/mozilla/trunk/modules/oji/src/ProxyJNI.cpp, line 1729
For application/x-java-vm found plugin
/usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
For application/x-java-vm found plugin
/usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1
nsPluginNativeWindowGtk2: call SetWindow with xid=0x2003ac4

Program ./firefox-bin (pid = 6610) received signal 11.
Stack:
UNKNOWN [./firefox-bin +0x0004F27B]
__kernel_sigreturn+0x00000000 [ +0x00000500]
JavaPluginInstance5::SetWindow(JDPluginWindow*)+0x0000018D
[/usr/java/jre1.6.0_01/lib/i386/libjavaplugin_nscp.so +0x00011A1D]
CNSAdapter_JavaPlugin::SetWindow(nsPluginWindow*)+0x00000047
[/usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so +0x0000FCA7]
UNKNOWN [./firefox-bin +0x0033485A]
UNKNOWN [./firefox-bin +0x0032A892]
UNKNOWN [./firefox-bin +0x0049289D]
UNKNOWN [./firefox-bin +0x00492E75]
UNKNOWN [./firefox-bin +0x00A9739E]
UNKNOWN [./firefox-bin +0x00A983C1]
UNKNOWN [./libxpcom_core.so +0x000A8796]
NS_ProcessNextEvent_P(nsIThread*, int)+0x00000087 [./libxpcom_core.so
+0x00037E2F]
UNKNOWN [./firefox-bin +0x00359DA8]
UNKNOWN [./firefox-bin +0x00D32C41]
UNKNOWN [./firefox-bin +0x0002F97A]
UNKNOWN [./firefox-bin +0x00027767]
__libc_start_main+0x000000DC [/lib/libc.so.6 +0x00015F2C]
Sleeping for 300 seconds.
Type 'gdb ./firefox-bin 6610' to attach your debugger to this thread.

(gdb) backtrace
#0  0xffffe405 in __kernel_vsyscall ()
#1  0x00a6acb6 in nanosleep () from /lib/libc.so.6
#2  0x00a6aadf in sleep () from /lib/libc.so.6
#3  0x08095ce4 in ah_crap_handler (signum=11) at nsSigHandlers.cpp:135
#4  0x0809727b in nsProfileLock::FatalSignalHandler (signo=11)
    at nsProfileLock.cpp:210
#5  <signal handler called>
#6  0x00ba0596 in XSync () from /usr/lib/libX11.so.6
#7  0xf5f67a1d in JavaPluginInstance5::SetWindow ()
   from /usr/java/jre1.6.0_01/lib/i386/libjavaplugin_nscp.so
#8  0xf622cca7 in CNSAdapter_JavaPlugin::SetWindow ()
   from /usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
#9  0x0837c85a in nsPluginNativeWindowGtk2::CallSetWindow (this=0xae637a0, 
    aPluginInstance=@0xffda52b8)
    at /home/wag/mozilla/trunk/modules/plugin/base/src/nsPluginNativeWindowGtk2.cpp:144
#10 0x08372892 in nsPluginHostImpl::InstantiateEmbeddedPlugin (this=0xa7ad188, 
    aMimeType=0xae5ffe0 "application/x-java-vm", aURL=0xae5fda8, 
    aOwner=0xae54ba8)
    at /home/wag/mozilla/trunk/modules/plugin/base/src/nsPluginHostImpl.cpp:3517
#11 0x084da89d in nsObjectFrame::InstantiatePlugin (this=0xae715a8, 
    aPluginHost=0xa7ad18c, aMimeType=0xae5ffe0 "application/x-java-vm", 
    aURI=0xae5fda8)
    at /home/wag/mozilla/trunk/layout/generic/nsObjectFrame.cpp:782
#12 0x084dae75 in nsObjectFrame::Instantiate (this=0xae715a8, 
    aMimeType=0xae5ffe0 "application/x-java-vm", aURI=0xae5fda8)
    at /home/wag/mozilla/trunk/layout/generic/nsObjectFrame.cpp:1428
#13 0x08adf39e in nsObjectLoadingContent::Instantiate (this=0xae5f33c, 
    aMIMEType=@0xae5feb4, aURI=0xae5fda8)
    at /home/wag/mozilla/trunk/content/base/src/nsObjectLoadingContent.cpp:1388
#14 0x08ae03c1 in nsAsyncInstantiateEvent::Run (this=0xae5fea0)
    at /home/wag/mozilla/trunk/content/base/src/nsObjectLoadingContent.cpp:143
#15 0xf7e74796 in nsThread::ProcessNextEvent (this=0x92a9f58, mayWait=1, 
    result=0xffda5600)
    at /home/wag/mozilla/trunk/xpcom/threads/nsThread.cpp:482
#16 0xf7e03e2f in NS_ProcessNextEvent_P (thread=0x92a9f58, mayWait=1)
    at nsThreadUtils.cpp:227
#17 0x083a1da8 in nsBaseAppShell::Run (this=0x976ff80)
    at /home/wag/mozilla/trunk/widget/src/xpwidgets/nsBaseAppShell.cpp:154
#18 0x08d7ac41 in nsAppStartup::Run (this=0x97a04c0)
    at /home/wag/mozilla/trunk/toolkit/components/startup/src/nsAppStartup.cpp:171
#19 0x0807797a in XRE_main (argc=1, argv=0xffda5bf4, aAppData=0x928a368)
    at /home/wag/mozilla/trunk/toolkit/xre/nsAppRunner.cpp:2887
#20 0x0806f767 in main (argc=1, argv=0xffda5bf4)
    at /home/wag/mozilla/trunk/browser/app/nsBrowserApp.cpp:87

Comment 3

[walter sheets]

I get exactly the same backtrace on 32-bit linux using either
java1.4 or 1.5 plug-in.

Comment 4

[Karl Tomlinson (:karlt)]

Reproduced here.  Thank you for reporting.

Comment 5

[Karl Tomlinson (:karlt)]

Similar stack on amd64 with blackdown plugin:

#5  0x00002ade5c393b37 in XSync () from /usr/lib/libX11.so.6
#6  0x00002aaab1832372 in JavaPluginInstance5::SetWindow ()
   from /opt/blackdown-jdk-1.4.2.03/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#7  0x00002aaab1700ecf in nsPluginNativeWindowGtk2::CallSetWindow (
    this=0x19297b0, aPluginInstance=@0x7fff5099b750)
    at /home/karl/moz/mozilla/modules/plugin/base/src/nsPluginNativeWindowGtk2.cpp:144

blackdown does not use XEmbed.
sun-1.6 says it needs XEmbed before the first SetWindow call.
Placing an XSync in nsPluginNativeWindowGtk2::CallSetWindow immediately before the aPluginInstance->SetWindow does not change the position of the crash.

Comment 6

[Karl Tomlinson (:karlt)]

Putting ws_info = nsnull, instead of = &m_ws_info in the nsPluginNativeWindowGtk2 constructor works around the crash with blackdown and sun plugins, but will cause other plugins to have problems.

I'm guessing that the javaplugin may be assuming that *window->ws_info is set appropriately if window->ws_info is non-NULL, but allocating and initializing the structure itself if it is NULL (as it used to be before the checkin for bug 384845).

Comment 7

[Karl Tomlinson (:karlt)]

This problem will exist in any X11 plugins using the deprecated nsIPluginInstance, which is apparently required for an OJI plugin:

  http://www.mozilla.org/oji/oji-intro.html

Is this documentation superseded?

Comment 9

[Karl Tomlinson (:karlt)]

Attachment: test patch

Are you able to test that the plugin functions as expected with this patch, please?

This patch is not suitable for checkin.  It is a quick hack, but if it functions correctly then that'll help me work out what should be done.

Comment 10

[Karl Tomlinson (:karlt)]

(In reply to comment #7)
> This problem will exist in any X11 plugins using the deprecated
> nsIPluginInstance,

That is _could_ exist with XPCOM plugins on X11.

> Is this documentation superseded?

I guess it will be:

http://boomswaggerboom.wordpress.com/2007/04/16/javaplugin-cleanup-for-mozilla-20/

Are there any other XPCOM plugins out there for unix?

Comment 11

[Bill Gianopoulos [:WG9s]]

(In reply to comment #9)
> Created an attachment (id=271334) [details]
> test patch
> 
> Are you able to test that the plugin functions as expected with this patch,
> please?

I am running with this patch and it seems to have resolved the JAVA crashes.  I have also not yet run into any other new plugin issues.  I will continue to use this as my default browser and report back if I find any new issues.

Also, if you put code like the following at the same place where this patch is inserted you can put in special code which will be executed for the JAVA OJI case only.

#ifdef OJI
  NS_INTERFACE_MAP_ENTRY(nsIJVMPluginTagInfo)
#endif


 ...


#ifdef OJI
  nsCOMPtr<nsIPluginInstance> instance = do_QueryInterface(pi, &rv);
  if (NS_SUCCEEDED(rv)) {
    nsCOMPtr<nsIJVMPluginInstance> javaInstance(do_QueryInterface(instance));
    if (javaInstance) {
      // CODE HERE WILL ONLY BE EXECUTED FOR JAVA PLUGINS.
    }
  }
#endif

Comment 12

[Bill Gianopoulos [:WG9s]]

(In reply to comment #10)
> 
> Are there any other XPCOM plugins out there for unix?
> 

I think the Totem plugin might be.  Hard to tell because it crashes on trunk anyway for other reasons even without the patch for bug 384845.

Comment 13

[Bill Gianopoulos [:WG9s]]

This totem bug report on the earlier crash I encountered would seem to indicate that it might be.

http://bugzilla.gnome.org/show_bug.cgi?id=354490

Comment 16

[Karl Tomlinson (:karlt)]

Although the totem plugin uses XPCOM it uses NPAPI, not the XPCOM Plugin API:

  http://web.archive.org/web/20000815060442/www.mozilla.org/docs/plugin.html

The easiest way to tell the difference is to look for the entry point function.  NPAPI plugins will have NP_Initialize defined where XPCOM plugins will have NSGetFactory.

Comment 17

[Karl Tomlinson (:karlt)]

What is happening in this bug (as analyzed with x86 Linux Sun Java 1.6.0.00,
and with x86_64 Blackdown Java 1.4.2.03) is that
JavaPluginInstance5::SetWindow calls nsPluginHostImpl::GetValue for
nsPluginManagerVariable_XDisplay and then calls XSync on this Display*.  This
XSync call is successful.

However, if ws_info is non-NULL, JavaPluginInstance5::SetWindow then calls
XSync on the Display* from window->ws_info.display.  It may seem strange to
call XSync twice, but if an xtbin had been set up then its Display would have
been different from that of GDK_DISPLAY used in nsPluginHostImpl::GetValue and
elsewhere.  (Don't ask me why the xtbin needs a different Display structure!)

Before the checkin of attachment 269360 [details] [diff] [review] in bug 384845, ws_info was NULL when
calling SetWindow for XPCOM plugins from
nsPluginNativeWindowGtk2::CallSetWindow.  At that stage ws_info was allocated
in ns4xPluginInstance::SetWindow for NPAPI plugins only.

Bug 384845 needed to use properties of the drawing surface to set ws_info
appropriately for windowless plugins.  These properties were not available in
ns4xPluginInstances so ws_info was allocated in nsPluginNativeWindowGtk2,
making ws_info available in nsObjectFrame, and making the ws_info pointer
non-NULL in nsPluginNativeWindowGtk2::CallSetWindow.

However, for windowed plugins the ws_info structure was still not filled out, so ws_info.display is NULL and XSyncing this Display gives the crash.  The test patch filled out the ws_info structure before the call to JavaPluginInstance5::SetWindow.  Thank you Bill for testing that the plugin functioned correctly when this was set.

Comment 18

[Karl Tomlinson (:karlt)]

Attachment: move ws_info and xtbin code from ns4xPluginInstance to nsPluginNativeWindowGtk2

Here's how I'd like to fix this bug.

The patch moves the ws_info information code from ns4xPluginInstance to
nsPluginNativeWindowGtk2 (which IMHO is where it should be anyway).

For XEmbed plugins, like libjavaplugin_oji.so from Sun Java 1.5 and 1.6, this
patch causes the plugin API to function, equivalently to the test patch above
(but the values will always be correct).  I have tested this patch with
plugins from x86 Sun Java 1.5 and 1.6 at the URLs in this bug and bug 386933.

However, to move _all_ of the ws_info code, the xtbin code needed to be moved
also.  The xtbin creation corresponds to the XEmbed socket creation, so the
two should both be in nsPluginNativeWindowGtk2 anyway.

The side effect of this is that non-XEmbed XPCOM plugins now have a window
from an Xt widget in window->window instead of a window from a GTK widget.
This could cause a problem if a plugin is assuming that the window has an
associated GdkWindow or GtkWidget.  However testing with x86 Blackdown Java
1.4.2.03 plugin (which does not use XEmbed) at the URLs in this bug and bug 386933 shows no problems.  (The x86_64 plugin worked as well or badly as it did with FF2.)

A possible improvement to this patch could be to refrain from creating an
xtbin and set ws_info to NULL if the plugin is XPCOM and non-XEmbed,
maintaining maximum backward compatibility.  However, as the XPCOM plugin API
is deprecated, the only known XPCOM plugin is libjavaplugin_oji, and the
latest versions of this plugin use XEmbed, there seems little point in
introducing what would be a hack.

Comment 19

[walter sheets]

Hi Karl,
This latest patch no longer applies cleanly to trunk so I can't test it.
Any chance of an update?

Comment 20

[Karl Tomlinson (:karlt)]

Hi Walter,
The current patch should apply with the -F5 (--fuzz 5) option to patch.
Thanks for testing!

Comment 21

[walter sheets]

Java, Flash, and Real plugins work fine now.  Those are the
only plugins I have.  Thanks Karl.

Comment 25

[Bill Gianopoulos [:WG9s]]

I have been running with this patch for 4 weeks now.  I have not experienced any JAVA crashes, nor have I found any other plugins that behave badly as a result of having this code installed.

Comment 26

[walter sheets]

I agree that firefox-trunk works well, but seamonkey-trunk still crashes with
java applets.  Apparently, Karl's patch is already in CVS (or I forgot that
I already applied it to my seamonkey src).  I just sent in a crash report from
the latest nightly build.

Comment 27

[Karl Tomlinson (:karlt)]

(In reply to comment #26)
> Apparently, Karl's patch is already in CVS (or I forgot that
> I already applied it to my seamonkey src).  I just sent in a crash report from
> the latest nightly build.

The patch here is not in CVS, as it is still awaiting review.
Do you see this crash with a patched seamonkey?

Comment 28

[Bill Gianopoulos [:WG9s]]

I just checked out the current Seamonkey trunk, applied this patch and built it.  I cannot duplicate any of the crashes using that build.

Comment 29

[walter sheets]

Attachment: Backtrace from seamonkey-trunk java crash

Comment 30

[Karl Tomlinson (:karlt)]

(In reply to comment #29)
> Created an attachment (id=275366) [details]
> Backtrace from seamonkey-trunk java crash

I'm not understanding the state of your seamonkey build.
Does it have any of the patches in this bug?

If it is crashing when patched with attachment 271973 [details] [diff] [review]:

* Does it occur with any attempt to use the java plugin?
  (or is there a particular URL to reproduce?)

* Would you be able to revert the patch from attachment 271973 [details] [diff] [review] and test with
  attachment 271334 [details] [diff] [review], please?

Comment 31

[walter sheets]

The backtrace is from sm with patch 271973 applied, and I see crashes with all
three of my usual java applets which run normally on patched firefox-trunk.

I tried patch 271334 and get a completely different bt in libxpcom.so (with no
debugging symbols).  I'll start over fresh when I get home from work today.

Comment 32

[g2g591]

sorry to be uninformed, but how do you apply the patch?

Comment 33

[Karl Tomlinson (:karlt)]

(In reply to comment #32)

From the mozilla directory you can use

patch -p1 -F5 < /path/to/javaplugin-move-gtk-1.diff

Comment 34

[Karl Tomlinson (:karlt)]

(In reply to comment #31)
> The backtrace is from sm with patch 271973 applied, and I see crashes with all
> three of my usual java applets which run normally on patched firefox-trunk.
> 
> I tried patch 271334 and get a completely different bt in libxpcom.so (with no
> debugging symbols).  I'll start over fresh when I get home from work today.

Thanks for your help, walter.
I'm beginning to think that this is an unrelated issue.
The crash you report in JavaVM5::StartJavaVM -> CNSAdapter_NSPR::JD_Close looks like it is happening before hitting any of the code from patches here (which does make it hard to understand why the trace was different with different patches).

What backtrace do you see when none of the patches here are applied?
If it is different to the trace in the description of this bug, can you file another bug, please?

Comment 35

[Bill Gianopoulos [:WG9s]]

Also, make sure that in the seamonkey plugins folder the java plugin is defined as a symbolic link to the plugin in the intallation folder for java.  Copying the plugin library to the application plugins folder results in either it not working at all or crashes.

Comment 36

[Karl Tomlinson (:karlt)]

(In reply to comment #34)
> I'm beginning to think that this is an unrelated issue.

> If it is different to the trace in the description of this bug, can you file
> another bug, please?

Actually it looks like bug 345309 filed last year.

Comment 37

[walter sheets]

(In reply to comment #34)
> (In reply to comment #31)
> ...
> it is happening before hitting any of the code from patches here (which
> does make it hard to understand why the trace was different with different
> patches).

Seems the bt was an anomaly this morning, dunno why.  On starting over I see
that the bt is the same with or without your two patches.

> What backtrace do you see when none of the patches here are applied?
> If it is different to the trace in the description of this bug, can you file
> another bug, please?

Sure.  Any suggestions for a helpful title?

Comment 38

[Karl Tomlinson (:karlt)]

(In reply to comment #37)

It looks the same as bug 345309 so unless you think otherwise, another bug is probably not needed.  Maybe change the title from opensolaris to "opensolaris and linux".  Unfortunately we don't seem to be able to set more than one OS: All or other, maybe.

Comment 39

[Ian Neal]

Been running with this patch for a good month or so now, not had any crashes and use java-enable sites most days, hours at a time.

Comment 40

[Johnny Stenback (:jst)]

Comment on attachment 271973 [details] [diff] [review]
move ws_info and xtbin code from ns4xPluginInstance to nsPluginNativeWindowGtk2

Seems reasonable to me. Let's get this in for the beta and see how it does.

Comment 41

[Reed Loden [:reed]]

Checking in modules/plugin/base/src/ns4xPluginInstance.cpp;
/cvsroot/mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp,v  <--  ns4xPluginInstance.cpp
new revision: 1.142; previous revision: 1.141
done
Checking in modules/plugin/base/src/ns4xPluginInstance.h;
/cvsroot/mozilla/modules/plugin/base/src/ns4xPluginInstance.h,v  <--  ns4xPluginInstance.h
new revision: 1.41; previous revision: 1.40
done
Checking in modules/plugin/base/src/nsPluginNativeWindowGtk2.cpp;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginNativeWindowGtk2.cpp,v  <--  nsPluginNativeWindowGtk2.cpp
new revision: 1.9; previous revision: 1.8
done
Checking in widget/src/gtkxtbin/gtk2xtbin.c;
/cvsroot/mozilla/widget/src/gtkxtbin/gtk2xtbin.c,v  <--  gtk2xtbin.c
new revision: 1.17; previous revision: 1.16
done