80960 - crash with about:plugins after nightly build 20010515

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P1)

Description

[Valdis Kletnieks]

RedHat 7.1, 2.4.4 kernel.

Downloaded the nightly 20010515 installer for Linux.  Downloaded the Java2 and
Flash plugins.  Installed, and then did a 'about:plugins'.  Mozilla promptly
rolled over and died.

Traceback:

Program received signal SIGSEGV, Segmentation fault.
0x400c4cca in nsCOMPtr_base::~nsCOMPtr_base () at eval.c:41
41      eval.c: No such file or directory.
        in eval.c
(gdb) where
#0  0x400c4cca in nsCOMPtr_base::~nsCOMPtr_base () at eval.c:41
#1  0x40dfe7b1 in nsPluginTag::TryUnloadPlugin ()
   from /home/valdis/mozilla/components/libgkplugin.so
#2  0x40dfe5d1 in nsPluginTag::~nsPluginTag ()
   from /home/valdis/mozilla/components/libgkplugin.so
#3  0x40e00783 in nsPluginHostImpl::ReloadPlugins ()
   from /home/valdis/mozilla/components/libgkplugin.so
#4  0x40a4fdd2 in PluginArrayImpl::Refresh ()
   from /home/valdis/mozilla/components/libjsdom.so
#5  0x40a5001e in PluginArrayImpl::Refresh ()
   from /home/valdis/mozilla/components/libjsdom.so
#6  0x400cf7d1 in XPTC_InvokeByIndex () at eval.c:41
#7  0x404a0919 in XPCWrappedNative::CallMethod ()
   from /home/valdis/mozilla/components/libxpconnect.so
#8  0x404a5805 in XPC_WN_CallMethod () from /home/valdis/mozilla/components/libx
pconnect.so
#9  0x4012ec65 in js_Invoke () at eval.c:41
#10 0x40136092 in js_Interpret () at eval.c:41
#11 0x4012f0a1 in js_Execute () at eval.c:41
#12 0x401134e5 in JS_EvaluateUCScriptForPrincipals () at eval.c:41
#13 0x40a37f1f in nsJSContext::EvaluateString ()
   from /home/valdis/mozilla/components/libjsdom.so
#14 0x40c07eaa in HTMLContentSink::EvaluateScript ()
   from /home/valdis/mozilla/components/libgkcontent.so
#15 0x40c098db in HTMLContentSink::ProcessSCRIPTTag ()
   from /home/valdis/mozilla/components/libgkcontent.so
#16 0x40c04669 in HTMLContentSink::AddLeaf ()
   from /home/valdis/mozilla/components/libgkcontent.so
#17 0x4091e2d7 in CNavDTD::AddLeaf () from /home/valdis/mozilla/components/libht
mlpars.so
#18 0x4091c50b in CNavDTD::HandleScriptToken ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#19 0x4091dae7 in CNavDTD::OpenContainer ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#20 0x4091abdd in CNavDTD::HandleDefaultStartToken ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#21 0x4091b746 in CNavDTD::HandleStartToken ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#22 0x4091a14a in CNavDTD::HandleToken ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#23 0x409193d3 in CNavDTD::BuildModel ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#24 0x4092ce13 in nsParser::BuildModel ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#25 0x4092cc59 in nsParser::ResumeParse ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#26 0x4092d5ec in nsParser::OnDataAvailable ()
   from /home/valdis/mozilla/components/libhtmlpars.so
#27 0x4096e07f in nsDocumentOpenInfo::OnDataAvailable ()
   from /home/valdis/mozilla/components/liburiloader.so
#28 0x408c67ff in nsJARChannel::OnDataAvailable ()
   from /home/valdis/mozilla/components/libnecko.so
#29 0x4089287e in nsOnDataAvailableEvent::HandleEvent ()
   from /home/valdis/mozilla/components/libnecko.so
#30 0x40892158 in nsARequestObserverEvent::HandlePLEvent ()
   from /home/valdis/mozilla/components/libnecko.so
#31 0x400bc807 in PL_HandleEvent () at eval.c:41
#32 0x400bc726 in PL_ProcessPendingEvents () at eval.c:41
#33 0x400bd6b8 in nsEventQueueImpl::ProcessPendingEvents () at eval.c:41
#34 0x404e59d3 in event_processor_callback ()
   from /home/valdis/mozilla/components/libwidget_gtk.so
#35 0x404e574d in our_gdk_io_invoke ()
   from /home/valdis/mozilla/components/libwidget_gtk.so
#36 0x4069c01e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#37 0x4069d7f3 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#38 0x4069ddd9 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#39 0x4069df8c in g_main_run () from /usr/lib/libglib-1.2.so.0
#40 0x405b5803 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#41 0x404e5ecc in nsAppShell::Run () from /home/valdis/mozilla/components/libwid
get_gtk.so
#42 0x404c6cea in nsAppShellService::Run ()
   from /home/valdis/mozilla/components/libnsappshell.so
#43 0x0804d1c4 in main1 () at eval.c:41
#44 0x0804da15 in main () at eval.c:41
#45 0x401f4237 in __libc_start_main () from /lib/libc.so.6

Comment 1

[shrirang khanzode]

hmm? i am blocked by bug 80170. cannot download the java plugin at all. What did  
you do to get it working ?Thanks ! Changing component to OJI

Comment 2

[Xiaobin Lu]

   Shrir:
      I don't know what happened with these xpi file. What did they change? I 
heard from ssu that there was a problem with the xpi file days ago and I don't 
know whether they have fixed it or not.

Comment 3

[shrirang khanzode]

oh ok..i see this. I waited paitiently and the plugin actually downlaoded after 
5-10 minutes..heh. Also, I see the crash after I restarted the browser and did 
"about:plugins". 

Comment 4

[shrirang khanzode]

xiaobin, the java plugin did get installed at last after I waited 
patiently...but that is bad. Pls see my comment in bug 80170 . 

Comment 5

[Peter Lubczynski]

taking, I Xiaobin, can you try my patch?

Comment 6

[Valdis Kletnieks]

Seee bug 80964 for a work-around for the download problem...

Comment 7

[Xiaobin Lu]

Peter: is the patch for bug78150? I think that's only affect Window, right?

Comment 8

[Peter Lubczynski]

Attachment: patch to reorder shutdown for XPCOM plugins and prevent Java crash

Comment 9

[Peter Lubczynski]

yes, bug 78150 not only only effects windows but is also turned off by a pref by 
default. That's not it, it's the scoping of nsCOMPtr in TryUnloadPlugins. All 
that nsCOMPtr stuff needs to be scoped out because it auto addref/releases.

Comment 10

[Xiaobin Lu]

  I will pulled the trunk and apply your patch today!

Comment 11

[Peter Lubczynski]

Oops..try this, it probably compiles better:

{
  nsCOMPtr<nsIJVMPlugin> isJava;
  if (mEntryPoint)
    isJava = do_QueryInterface(mEntryPoint);

  if (isJava) return; // the Shutdown and release call should go through 
}

Comment 12

[Xiaobin Lu]

Peter: I have tried it in Linux build and there is no assertion finally when I 
shutdown the browser with an applet page.

Shrir: Did you try the patch in Windows? I remeber you had comment about the 
patch somewhere. 

Comment 13

[Peter Lubczynski]

But if so, does it fix this bug? If so, can I get an r= from you to check this 
in. Many dups.

Comment 14

[Xiaobin Lu]

Peter: 
   I will take a look at this bug and if your patch really solves the 
"shutdown assertion", we defintely need to check it into the trunk.

 

Comment 15

[Xiaobin Lu]

Peter:
   I can see that your patch solves the shutdown assertion problem. However, 
will that solves the problem mentioned here?

Comment 16

[shrirang khanzode]

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

Comment 17

[Keyser Sose]

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

Comment 18

[sean echevarria]

bug 80955 was incorrectly marked a dupe of this.  If you don't feel like 
reopening it then someone needs to make sure that the second patch for bug 
76936 (to fix the nsComPtr release) gets onto the trunk (it made it into the 
0.9 branch but not the trunk).

Comment 19

[Peter Lubczynski]

okay, the patch in bug 80955 was checked in. This should be fixed? Please try. 
Leaving open until someone on Linux with Java can confirm.

Comment 20

[sean echevarria]

The patch for bug 80955 won't address this crash.  These are similar but
distinct bugs.  bug 80955 was specifically about a crash at shutdown.  This one
is about a crash when viewing about:plugins.  The about:plugins page contains
javascript that calls navigator.plugins.refresh(false) which does an unload of
all stopped plugins.  Need to prevent the forced unload of Java when
ReloadPlugins is called.

That is, we need yet another Java specific hack similar to bug 80955 in
nsPluginHostImpl::IsRunningPlugin(nsPluginTag * plugin) so that IsRunningPlugin
always returns PR_TRUE when the plugin argument is a JVM impl - regardless of
whether or not it is stopped.

Something like this should plug this hole:

PRBool nsPluginHostImpl::IsRunningPlugin(nsPluginTag * plugin)
{
  if(!plugin)
    return PR_FALSE;
+
+  // XXX Another hack to keep Java loaded, see bug 80960
+  if (plugin->mEntryPoint) {
+    nsCOMPtr<nsIJVMPlugin> jvm = do_QueryInterface(plugin->mEntryPoint);
+    if (jvm) {
+      return PR_TRUE
+    }
+  }

Comment 21

[Peter Lubczynski]

I just FIXED this. Please re-open if this is a problem.

Comment 22

[shrirang khanzode]

tried with today's trunk on linux (2001051708). Installed java plugin, 
flashplayer. Did "about:plugins". List comes up fine, no crash. VERIFIED.

Comment 23

[Peter Lubczynski]

Shrirang, did you visit a page with Java before doing about:plugins in 
verification? That is important to "start" Java.

Comment 24

[shrirang khanzode]

yup, works fine either ways (just after launch / afterloading applet).

Comment 25

[sean echevarria]

what about going to a page with an applet after doing about:plugins?

Comment 26

[shrirang khanzode]

tried that too..browser stands it's ground  :)

Comment 27

[Peter Lubczynski]

Sean, you think extending this to all XPCOM plugins (not 4x ones) would work 
too?

Comment 28

[sean echevarria]

Shrir: Cool - confused, but cool.  I was under the impression that the Java 
plugin couldn't be shutdown midsession without breaking it.  I thought a 
midsession shutdown would be caused by loading a page with an applet, doing 
about:plugins and then loading another page with an applet.

Peter: Not sure whay you mean.  Extend what to all XPCOM plugins?