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

VERIFIED FIXED in mozilla1.9beta1

Status

()

defect
--
critical
VERIFIED FIXED
12 years ago
8 years ago

People

(Reporter: wgianopoulos, Assigned: karlt)

Tracking

({crash, regression})

Trunk
mozilla1.9beta1
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, )

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

12 years ago
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 ?? ()
Reporter

Comment 1

12 years ago
I should have mentioned this is with:

Java(TM) Plug-in 1.6.0_01-b06
Reporter

Comment 2

12 years ago
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

12 years ago
I get exactly the same backtrace on 32-bit linux using either
java1.4 or 1.5 plug-in.
Reproduced here.  Thank you for reporting.
Status: NEW → ASSIGNED
Assignee: nobody → mozbugz
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
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).
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?
Duplicate of this bug: 386933
Posted patch test patch (obsolete) — Splinter Review
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.
(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?
Reporter

Comment 11

12 years ago
(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
Reporter

Comment 12

12 years ago
(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.
Reporter

Comment 13

12 years ago
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

Updated

12 years ago
Duplicate of this bug: 387532

Updated

12 years ago
Blocks: 351840

Updated

12 years ago
Flags: blocking1.9?
Summary: Crash when running Java Applets → Crash when running Java Applets [@ XSync - JavaPluginInstance5::SetWindow]

Updated

12 years ago
Duplicate of this bug: 387837
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.
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.
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.
Attachment #271334 - Attachment is obsolete: true
Attachment #271973 - Flags: superreview?(jst)
Attachment #271973 - Flags: review?(jst)
Flags: blocking1.9? → blocking1.9+

Comment 19

12 years ago
Hi Karl,
This latest patch no longer applies cleanly to trunk so I can't test it.
Any chance of an update?
Hi Walter,
The current patch should apply with the -F5 (--fuzz 5) option to patch.
Thanks for testing!

Comment 21

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

Updated

12 years ago
Duplicate of this bug: 389405

Updated

12 years ago
Duplicate of this bug: 389960

Updated

12 years ago
Duplicate of this bug: 389950
Reporter

Comment 25

12 years ago
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

12 years ago
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.
(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?
Reporter

Comment 28

12 years ago
I just checked out the current Seamonkey trunk, applied this patch and built it.  I cannot duplicate any of the crashes using that build.
(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

12 years ago
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

12 years ago
sorry to be uninformed, but how do you apply the patch?
(In reply to comment #32)

From the mozilla directory you can use

patch -p1 -F5 < /path/to/javaplugin-move-gtk-1.diff
(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?
Reporter

Comment 35

12 years ago
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.
(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.
Blocks: 345309

Comment 37

12 years ago
(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?


(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

12 years ago
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 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.
Attachment #271973 - Flags: superreview?(jst)
Attachment #271973 - Flags: superreview+
Attachment #271973 - Flags: review?(jst)
Attachment #271973 - Flags: review+
Attachment #271973 - Flags: approval1.9+
Whiteboard: [apply patch with -F5]
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
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M9
Reporter

Updated

12 years ago
Status: RESOLVED → VERIFIED

Updated

12 years ago
Flags: in-testsuite?
Whiteboard: [apply patch with -F5]
Crash Signature: [@ XSync - JavaPluginInstance5::SetWindow]
You need to log in before you can comment on or make changes to this bug.