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

Don Lewis truckman at FreeBSD.org
Tue Feb 7 11:27:39 UTC 2006


On  6 Feb, FreeBSD-gnats-submit at 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





More information about the freebsd-ports-bugs mailing list