firefox-1.5 core dumps when attempting to load jdk14 plugin, but only on 4.11-STABLE

Don Lewis truckman at freebsd.org
Mon Feb 6 09:10:53 PST 2006


>Submitter-Id:	current-users
>Originator:	Don Lewis
>Organization:	FreeBSD Project
>Confidential:	no 
>Synopsis:	firefox-1.5 core dumps when attempting to load jdk14 plugin, but only on 4.11-STABLE
>Severity:	serious
>Priority:	medium
>Category:	ports
>Class:		sw-bug
>Release:	FreeBSD 4.11-STABLE i386
>Environment:
System: FreeBSD mousie.catspoiler.org 4.11-STABLE FreeBSD 4.11-STABLE #27: Sat Feb 4 05:21:17 PST 2006 dl at 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:

	




More information about the freebsd-gnome mailing list