From dl@mousie.catspoiler.org  Mon Feb  6 17:10:53 2006
Return-Path: <dl@mousie.catspoiler.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5349B16A422;
	Mon,  6 Feb 2006 17:10:53 +0000 (GMT)
	(envelope-from dl@mousie.catspoiler.org)
Received: from mousie.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 78CD043D46;
	Mon,  6 Feb 2006 17:10:52 +0000 (GMT)
	(envelope-from dl@mousie.catspoiler.org)
Received: from mousie.catspoiler.org (localhost [127.0.0.1])
	by mousie.catspoiler.org (8.13.4/8.13.1) with ESMTP id k16HApPt053116;
	Mon, 6 Feb 2006 09:10:51 -0800 (PST)
	(envelope-from dl@mousie.catspoiler.org)
Received: (from dl@localhost)
	by mousie.catspoiler.org (8.13.4/8.13.1/Submit) id k16HApUt053115;
	Mon, 6 Feb 2006 09:10:51 -0800 (PST)
	(envelope-from dl)
Message-Id: <200602061710.k16HApUt053115@mousie.catspoiler.org>
Date: Mon, 6 Feb 2006 09:10:51 -0800 (PST)
From: Don Lewis <truckman@freebsd.org>
Reply-To: Don Lewis <truckman@freebsd.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: gnome@freebsd.org
Subject: firefox-1.5 core dumps when attempting to load jdk14 plugin, but only on 4.11-STABLE
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         92901
>Category:       ports
>Synopsis:       firefox-1.5 core dumps when attempting to load jdk14 plugin, but only on 4.11-STABLE
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnome
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 06 17:20:03 GMT 2006
>Closed-Date:    Sat May 27 16:30:18 GMT 2006
>Last-Modified:  Sat May 27 16:30:18 GMT 2006
>Originator:     Don Lewis
>Release:        FreeBSD 4.11-STABLE i386
>Organization:
FreeBSD Project
>Environment:
System: FreeBSD mousie.catspoiler.org 4.11-STABLE FreeBSD 4.11-STABLE #27: Sat Feb 4 05:21:17 PST 2006 dl@mousie.catspoiler.org:/usr/obj/usr/src/sys/GENERICDDB i386

	FreeBSD 4.11-STABLE
	i386
	firefox-1.5.0.1,1
	jdk-1.4.2p8_2

The problem does not occur on FreeBSD 7.0-CURRENT, or with
mozilla-1.7.12_5,2 on 4.11-STABLE.

>Description:

Firefox-1.5 dumps core when it loads the jdk14 extension.  This only
seems to happen on my 4.11-STABLE, i136 machine.  This problem
does not occur on my 7-CURRENT, i386 box.  In both cases, jdk-1.4.2p8_2
is installed.  Also, mozilla-1.7.12_5,2 seems to work on my 4.11-STABLE
machine.

The problem seems to be the incorrect "this" pointer being passed to
nsComponentManagerImpl::GetFactoryEntry(), causing mFactorys.ops to
be NULL.

If I set a breakpoint in nsComponentManagerImpl::Init(), I see one
value for "this":

Breakpoint 1, nsComponentManagerImpl::Init (this=0x808ea00, 
    aStaticModules=0x806c3e8, aStaticModuleCount=1)
    at nsComponentManager.cpp:728
728     PR_ASSERT(mShuttingDown != NS_SHUTDOWN_INPROGRESS);

When firefox attempts to load the plugin:

Plugin() /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so returned 88f9560

Program received signal SIGSEGV, Segmentation fault.
0x281a76d5 in PL_DHashTableOperate (table=0x8089ba2, key=0x2a76f9dc, 
    op=PL_DHASH_LOOKUP) at pldhash.c:492
492     keyHash = table->ops->hashKey(table, key);
Current language:  auto; currently c
(gdb) where
#0  0x281a76d5 in PL_DHashTableOperate (table=0x8089ba2, key=0x2a76f9dc, 
    op=PL_DHASH_LOOKUP) at pldhash.c:492
#1  0x28204f43 in nsComponentManagerImpl::GetFactoryEntry (this=0x8089b76, 
    aClass=@0x2a76f9dc) at nsComponentManager.cpp:1622
#2  0x28206803 in nsComponentManagerImpl::RegisterService (this=0x8089b76, 
    aClass=@0x2a76f9dc, aService=0x8acf0c0) at nsComponentManager.cpp:2138
#3  0x2a763284 in CPluginServiceProvider::CPluginServiceProvider ()
   from /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so
#4  0x2a75cc3d in JavaPluginFactory5::JavaPluginFactory5 ()
   from /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so
#5  0x2a75c74e in JavaPluginFactory5::Create ()
   from /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so
#6  0x2a7436c2 in NSGetFactory ()
   from /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so
#7  0x2a71f333 in nsPluginFile::GetPluginInfo (this=0xbfbfa610, 
    info=@0xbfbfa620) at nsPluginsDirUnix.cpp:449
#8  0x2a7057af in nsPluginHostImpl::ScanPluginsDirectory (this=0x8ae8d00, 
    pluginsDir=0x8712b80, compManager=0x808ea00, aCreatePluginList=1, 
    aPluginsChanged=0xbfbfa7c4, checkForUnwantedPlugins=0)
    at nsPluginHostImpl.cpp:4947
#9  0x2a705b12 in nsPluginHostImpl::ScanPluginsDirectoryList (this=0x8ae8d00, 
    dirEnum=0x8acf140, compManager=0x808ea00, aCreatePluginList=1, 
    aPluginsChanged=0xbfbfa864, checkForUnwantedPlugins=0)
    at nsPluginHostImpl.cpp:5039
#10 0x2a705e3b in nsPluginHostImpl::FindPlugins (this=0x8ae8d00, 
    aCreatePluginList=1, aPluginsChanged=0xbfbfa90c)
    at nsPluginHostImpl.cpp:5122
#11 0x2a705bc1 in nsPluginHostImpl::LoadPlugins (this=0x0)
    at nsPluginHostImpl.cpp:5059
#12 0x2a703b76 in nsPluginHostImpl::IsPluginEnabledForType (this=0x8ae8d00, 
    aMimeType=0x29ba10f8 "application/x-oleobject")
    at nsPluginHostImpl.cpp:4065

[snip]

(gdb) up
#1  0x28204f43 in nsComponentManagerImpl::GetFactoryEntry (this=0x8089b76, 
    aClass=@0x2a76f9dc) at nsComponentManager.cpp:1622
(gdb) print mFactories
$1 = {ops = 0x0, data = 0x0, hashShift = 0, maxAlphaFrac = 0 '\0', 
  minAlphaFrac = 0 '\0', entrySize = 0, entryCount = 0, removedCount = 0, 
  generation = 0, entryStore = 0x0}


It seems odd to me that the ns610 plugin would use the NSGetFactory()
implementation in navig5/GetFactory5.cpp instead of the implementation
in ns6-adapter/NSGetFactory.cpp.

If I walk through the jdk code, it looks to me like the first argument
to NSGetFactory() should end up as "this" in stack frame #2, but if
I look at stack frame #7, where we call into the jdk plugin, the
first argument has some other value that doesn't seem to match anything
else:

(gdb) up
#7  0x2a71f333 in nsPluginFile::GetPluginInfo (this=0xbfbfa610, 
    info=@0xbfbfa620) at nsPluginsDirUnix.cpp:449
449         rv = nsGetFactory(mgr, kPluginCID, nsnull, nsnull, 
444         // Classic holdovers that live in the plugins directory but
445         // implement nsIPlugin and the factory stuff.
446         static NS_DEFINE_CID(kPluginCID, NS_PLUGIN_CID);
447
448         nsCOMPtr<nsIFactory> factory;
449         rv = nsGetFactory(mgr, kPluginCID, nsnull, nsnull, 
450         getter_AddRefs(factory));
451         if (NS_FAILED(rv)) return rv;
452
453         plugin = do_QueryInterface(factory);
(gdb) print mgr
$2 = (class nsIServiceManagerObsolete *) 0x808ea1c

Part of the reason for the discrepency might be that mgr in frame #7 is
(class nsIServiceManagerObsolete *), whereas frame #1 wants
(nsComponentManagerImpl *).

>How-To-Repeat:

Use firefox-1.5 on 4.11-STABLE to view a web page that has content that
triggers an attempt to load plugins.

>Fix:

	


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->gnome 
Responsible-Changed-By: edwin 
Responsible-Changed-When: Mon Feb 6 20:28:00 UTC 2006 
Responsible-Changed-Why:  
Over to maintainer 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92901 

From: Don Lewis <truckman@FreeBSD.org>
To: FreeBSD-gnats-submit@FreeBSD.org
Cc: freebsd-ports-bugs@FreeBSD.org
Subject: Re: ports/92901: firefox-1.5 core dumps when attempting to load
 jdk14 plugin, but only on 4.11-STABLE
Date: Tue, 7 Feb 2006 03:27:31 -0800 (PST)

 On  6 Feb, FreeBSD-gnats-submit@FreeBSD.org wrote:
 > Thank you very much for your problem report.
 > It has the internal identification `ports/92901'.
 > The individual assigned to look at your
 > report is: freebsd-ports-bugs. 
 > 
 > You can access the state of your problem report at any time
 > via this link:
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=92901
 > 
 >>Category:       ports
 >>Responsible:    freebsd-ports-bugs
 >>Synopsis:       firefox-1.5 core dumps when attempting to load jdk14 plugin, but only on 4.11-STABLE
 >>Arrival-Date:   Mon Feb 06 17:20:03 GMT 2006
 
 The mapping from this=0x808ea00 to 0x808ea1c is being done the
 NS_STATIC_CAST() in nsServiceManager::GetGlobalServiceManager() on line
 57 of nsServiceManagerObsolete.cpp, which is being called by
 nsPluginFile::GetPluginInfo() on line 434 of nsPluginsDirUnix.cpp.
 
 I built the jdk14 plugin with debugging info so I could fill in the gap
 in stack trace.
 
 #0  0x281a76d5 in PL_DHashTableOperate (table=0x8089ba2, key=0x2a76f9fc, 
     op=PL_DHASH_LOOKUP) at pldhash.c:492
 #1  0x28204f43 in nsComponentManagerImpl::GetFactoryEntry (this=0x8089b76, 
     aClass=@0x2a76f9fc) at nsComponentManager.cpp:1622
 #2  0x28206803 in nsComponentManagerImpl::RegisterService (this=0x8089b76, 
     aClass=@0x2a76f9fc, aService=0x88d92e0) at nsComponentManager.cpp:2138
 #3  0x2a7632ac in CPluginServiceProvider::CPluginServiceProvider (
     this=0x88d92e0, pProvider=0x808ea1c)
     at ../../../src/plugin/oji-plugin/src/motif/navig5/CPluginServiceProvider.cpp:64
 #4  0x2a75cc65 in JavaPluginFactory5::JavaPluginFactory5 (this=0x872e180, 
     pProvider=0x808ea1c)
     at ../../../src/plugin/oji-plugin/src/motif/navig5/JavaPluginFactory5.cpp:150
 #5  0x2a75c776 in JavaPluginFactory5::Create (sm=0x808ea1c, aIID=@0x2a768850, 
     aInstancePtr=0xbfbfa530)
     at ../../../src/plugin/oji-plugin/src/motif/navig5/JavaPluginFactory5.cpp:103
 #6  0x2a7436ea in NSGetFactory (pProvider=0x808ea1c, aClass=@0x2a725ec8, 
     aClassName=0x0, aProgID=0x0, aFactory=0xbfbfa530)
     at ../../../src/plugin/oji-plugin/src/motif/navig5/GetFactory5.cpp:72
 #7  0x2a71f333 in nsPluginFile::GetPluginInfo (this=0xbfbfa610, 
     info=@0xbfbfa620) at nsPluginsDirUnix.cpp:449
 #8  0x2a7057af in nsPluginHostImpl::ScanPluginsDirectory (this=0x8b8f680, 
     pluginsDir=0x8713a00, compManager=0x808ea00, aCreatePluginList=1, 
     aPluginsChanged=0xbfbfa7c4, checkForUnwantedPlugins=0)
     at nsPluginHostImpl.cpp:4947
 
 0x808ea1c is getting passed as far as frame #3, where it somehow gets
 mapped to 0x8089b76 instead of back to 0x808ea00 on line 64 in
 CPluginServiceProvider.cpp.  I don't understand c++ well enough to
 figure out what is going on here.
 
 (gdb) frame 3
 #3  0x2a7632ac in CPluginServiceProvider::CPluginServiceProvider (
     this=0x88d92e0, pProvider=0x808ea1c)
     at ../../../src/plugin/oji-plugin/src/motif/navig5/CPluginServiceProvider.cpp:64
 64      if (NS_FAILED(pProvider->QueryInterface(kIServiceManagerIID, (void**)&mService))) {
 (gdb) list
 59        mPluginManager(NULL), mJVMManager(NULL), mCookieStorage(NULL)
 60
 61  {
 62  #ifdef RAPTOR_API
 63      // Try to obtain nsIServiceManager if running inside Mozilla
 64      if (NS_FAILED(pProvider->QueryInterface(kIServiceManagerIID, (void**)&mService))) {
 65        plugin_error("Did not find the service manager!");
 66      }
 67  #else
 68      // We are running inside Mozilla classic. The provider is a plugin manager
 
 
 If I step through this code in gdb, this is what I see:
 
 Breakpoint 2, CPluginServiceProvider::CPluginServiceProvider (this=0x88d92e0, 
     pProvider=0x808ea1c)
     at ../../../src/plugin/oji-plugin/src/motif/navig5/CPluginServiceProvider.cpp:58
 58      : mService(NULL), mMgr(NULL), 
 (gdb) step
 64      if (NS_FAILED(pProvider->QueryInterface(kIServiceManagerIID, (void**)&mService))) {
 (gdb) step
 0x2820b264 in non-virtual thunk to nsComponentManagerImpl::RegisterService(nsID const&, nsISupports*) ()
     at ../../dist/include/string/nsTDependentSubstring.h:62
 62          {
 (gdb) step
 nsComponentManagerImpl::RegisterService (this=0x28b1846d, aClass=@0xbfbfa288, 
     aService=0x4) at nsComponentManager.cpp:2134
 2134   {
 (gdb) step
 245         : nsAutoLockBase((void*)mon, eAutoMonitor),
 (gdb) print this
 $8 = (nsComponentManagerImpl * const) 0x8089b76
 
 

From: "Jeremy Messenger" <mezz7@cox.net>
To: bug-followup@freebsd.org
Cc: truckman@freebsd.org
Subject: Re: ports/92901: firefox-1.5 core dumps when attempting to load jdk14 plugin, but only on 4.11-STABLE
Date: Fri, 26 May 2006 15:52:59 -0500

 Do you still have this problem with the current ports tree versions? I  
 don't understand the backtraces, so my guess is that Java built with GCC  
 2.9.x and Firefox built with GCC 3.x is causing this issue?
 
 Cheers,
 Mezz
 
 
 -- 
 mezz7@cox.net  -  mezz@FreeBSD.org
 FreeBSD GNOME Team
 http://www.FreeBSD.org/gnome/  -  gnome@FreeBSD.org
State-Changed-From-To: open->closed 
State-Changed-By: mezz 
State-Changed-When: Sat May 27 16:29:28 UTC 2006 
State-Changed-Why:  
We, FreeBSD GNOME Team, have agreed that we have no desire to support 4.x. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92901 
>Unformatted:
