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