416300 - Firefox - trunk build Version 3.0b4pre is crashing on AIX [@RegisterGenericFactory ]

Status: VERIFIED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Shailen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Below is the stack trace for the core generated

# dbx ./firefox-bin ./core
Type 'help' for help.
[using memory image in ./core]
reading symbolic information ...

Illegal instruction (illegal opcode) in . at 0x0 ($t1)
warning: Unable to access address 0x0 from core
(dbx) where
warning: Unable to access address 0xfffffffffffffffc from core
warning: Unable to access address 0xfffffffffffffffc from core
warning: Unable to access address 0xfffffffffffffffc from core
warning: Unable to access address 0xfffffffffffffffc from core
.() at 0x0
RegisterGenericFactory(nsIComponentRegistrar*,const nsModuleComponentInfo*)(0x110077750, 0x9001000a028eb78), line 277 in "nsXPComInit.cpp"
unnamed block $b1234, line 625 in "nsXPComInit.cpp"
unnamed block $b1233, line 625 in "nsXPComInit.cpp"
NS_InitXPCOM3_P(0xffffffffffff0a8, 0x110016490, 0xffffffffffff7d0, 0x9001000a02772b8, 0x100000001), line 625 in "nsXPComInit.cpp"
Initialize()(0xffffffffffff0a8), line 943 in "nsAppRunner.cpp"
unnamed block $b2178, line 1783 in "nsAppRunner.cpp"
ImportProfiles(nsIToolkitProfileService*,nsINativeAppSupport*)(0x110067690, 0x110067370), line 1783 in "nsAppRunner.cpp"
SelectProfile(nsIProfileLock**,nsINativeAppSupport*,int*,nsACString_internal*)(0xffffffffffff8b8, 0x110067370, 0xffffffffffffb54, 0xffffffffffff8c0), line 1948 in "nsAppRunner.cpp"
unnamed block $b2212, line 2858 in "nsAppRunner.cpp"
XRE_main(0x100000001, 0x203feab0, 0x110016330), line 2858 in "nsAppRunner.cpp"
main(argc = 1, argv = 0x00000000203feab0), line 158 in "nsBrowserApp.cpp"


Reproducible: Always

Steps to Reproduce:
1. 1.Build Mozilla Firefox Trunk build on AIX with Gnome RPMS of 64 bit
version.
2.
3.
Actual Results:  
Firefox crashes 

Expected Results:  
Firefox should not crash

Comment 1

[Shailen]

After debugging, below is what happned.

   1. /usr/bin/dbx ./firefox-bin
   2.      Type 'help' for help.
   3.      reading symbolic information ...
   4.      (/usr/bin/dbx) set -o vi
   5.      (/usr/bin/dbx) stop at "nsComponentManager.cpp":1610
   6.      [1] stop at "nsComponentManager.cpp":1610
   7.      (/usr/bin/dbx) c
   8.      WARNING: NS_ENSURE_TRUE(compMgr) failed: file nsComponentManagerUtils.cpp, line 90
   9.       WARNING: NS_ENSURE_TRUE(compMgr) failed: file nsComponentManagerUtils.cpp, line 90
  10.      WARNING: NS_ENSURE_TRUE(compMgr) failed: file nsComponentManagerUtils.cpp, line 90
  11.      [1] stopped in nsComponentManagerImpl::CreateInstance(const nsID&,nsISupports*,const nsID&,void**) at line 1610 in file "/home/sjain/sb/tinderbox/AIX_5.2_Clobber/mozilla/xpcom/components/nsComponentManager.cpp" ($t1)
  12.       1610       nsIFactory *factory = nsnull;
  13.      (/usr/bin/dbx) list
  14.       1611       nsresult rv = entry->GetFactory(&factory);
  15.       1612
  16.       1613       if (NS_SUCCEEDED(rv))
  17.       1614       {
  18.       1615           rv = factory->CreateInstance(aDelegate, aIID, aResult);
  19.       1616           if (NS_SUCCEEDED(rv) && !*aResult) {
  20.       1617               NS_ERROR("Factory did not return an object but returned success!");
  21.       1618               rv = NS_ERROR_SERVICE_NOT_FOUND;
  22.       1619           }
  23.       1620           NS_RELEASE(factory);
  24.      (/usr/bin/dbx) n
  25.      stopped in nsComponentManagerImpl::CreateInstance(const nsID&,nsISupports*,const nsID&,void**) at line 1611 in file "/home/sjain/sb/tinderbox/AIX_5.2_Clobber/mozilla/xpcom/components/nsComponentManager.cpp" ($t1)
  26.       1611       nsresult rv = entry->GetFactory(&factory);
  27.      (/usr/bin/dbx) step
  28.      stopped in nsFactoryEntry::GetFactory(nsIFactory**) at line 3450 in file "/home/sjain/sb/tinderbox/AIX_5.2_Clobber/mozilla/xpcom/components/nsComponentManager.cpp" ($t1)
  29.       3450   {
  30.      (/usr/bin/dbx) list
  31.       3451       if (!mFactory) {
  32.       3452           nsresult rv;
  33.       3453
  34.       3454           if (mLoaderType == NS_LOADER_TYPE_INVALID)
  35.       3455               return NS_ERROR_FAILURE;
  36.       3456
  37.       3457           nsCOMPtr<nsIModule> module;
  38.       3458
  39.       3459           if (mLoaderType == NS_LOADER_TYPE_STATIC) {
  40.       3460               rv = nsComponentManagerImpl::gComponentManager->
  41.      (/usr/bin/dbx) n
  42.      stopped in nsFactoryEntry::GetFactory(nsIFactory**) at line 3451 in file "/home/sjain/sb/tinderbox/AIX_5.2_Clobber/mozilla/xpcom/components/nsComponentManager.cpp" ($t1)
  43.       3451       if (!mFactory) {
  44.      (/usr/bin/dbx) n
  45.      stopped in unnamed block $b1697 at line 3454 in file "/home/sjain/sb/tinderbox/AIX_5.2_Clobber/mozilla/xpcom/components/nsComponentManager.cpp" ($t1)
  46.       3454           if (mLoaderType == NS_LOADER_TYPE_INVALID)
  47.      (/usr/bin/dbx) n
  48.      stopped in unnamed block $b1697 at line 3455 in file "/home/sjain/sb/tinderbox/AIX_5.2_Clobber/mozilla/xpcom/components/nsComponentManager.cpp" ($t1)
  49.       3455               return NS_ERROR_FAILURE; 

Comment 2

[Shailen]

I have built the trunk build 20 days ago and that time it worked fine.

After debugging the code, below is what I have observed.

With new build ( which dumps the core ), the registrar->RegisterFactory(info->mCID, info->mDescription,info->mContractID, fact) (in "nsXPComInit.cpp":273) is invoking nsComponentManagerImpl::CreateInstance(const nsCID &aClass, nsISupports *aDelegate,const nsIID &aIID, void **aResult).

Where as with the earlier build ( built 20days ago and wasnt dumping the core) the registrar->RegisterFactory(info->mCID, info->mDescription,info->mContractID, fact) (in nsXPComInit.cpp":277) is invoking nsComponentManagerImpl::RegisterFactory(const nsCID & aClass, const char *aClassName, const char *aContractID,nsIFactory *aFactory).

Note sure what prompted to call different functions from registrar->RegisterFactory? 

Comment 3

[Shailen]

Looks like the cause for the coredump is due to the Attachment #298502 [details] [diff] (  Fix more nits, rev. 1.6 ) of Bug 412320

Comment 4

[jag (Peter Annema)]

It seems something is wonky. Could you try doing a clean build (make clean; make)?

Comment 5

[Shailen]

jag: I tried doing a clean build and it is still crashing at the same point.

Comment 6

[jag (Peter Annema)]

Shailen: if you haven't done so already, can you confirm that it is indeed that change that's causing this crash?

Since a bunch of things have landed that depend on it, either back them all out, or check out by date just prior to the change to verify that build works, and again just after to verify that one breaks.

Comment 7

[Shailen]

I believe the modification related to 'nsComponentManager.cpp' ( Bug 412320) is what causing this issue. From bonsai, I found that, the file 'nsComponentManager.cpp' got modified on 2008-01-25. Hence I downloaded the trunk build with MOZ_CO_DATE set to 2008 Jan 23 and compiled. The build seems to be working fine.  

Comment 8

[Shailen]

Jag: As discussed, 

   I have taken the trunk build with MOZ_CO_DATE as  "25 Jan 2008 09:13:00 PST" and compiled. Build ran file without crash.

   Also I have taken the trunk build with MOZ_CO_DATE as  "25 Jan 2008 09:20:00 PST" and compiled. But build did not run fine and crashed at the same point @RegisterGenericFactory.

Comment 9

[jag (Peter Annema)]

Alright, so definitely the patch. Thanks for the file you sent me. Note that the changes for bug 412320 were backed out today, so I think we can close this bug was "works for me".

I'll have a look at the file you sent me to see what was wrong (just in case the changes get resurrected at some point).

Comment 10

[jag (Peter Annema)]

Resolving bug as WFM now that the changes for bug 412320 were backed out.

Shailen, if for some reason that didn't address your problem, please reopen this bug.

Comment 11

[Shailen]

jag: The core dump issue had been addressed with backing out changes for bug 412320 

Comment 12

[jag (Peter Annema)]

Shailen: thanks for confirming.