Apprunner on FreeBSD (3.1-STABLE, compiled with egcs 1.1.2, no ./configure options) crashes on startup if mozilla/dist/bin/components/libucvja.so has been changed (including having its mtime changed) since the last time the registry was updated. Illustration: bash-2.02$ touch ~/Mozilla/mozilla/dist/bin/components/libucvja.so bash-2.02$ ./mozilla-apprunner.sh MOZILLA_FIVE_HOME=/home/llennox/Mozilla/mozilla/dist/bin LD_LIBRARY_PATH=/home/llennox/Mozilla/mozilla/dist/bin MOZ_PROGRAM=apprunner nsComponentManager: Using components dir: /home/llennox/Mozilla/mozilla/dist/bin/components Bus error - core dumped Workaround: delete ~/.mozilla/registry before starting apprunner if that library has been changed. This seems to happen for the other 16-bit libucv*.so converters also, but not for libucvlatin.so. I think this is why the FreeBSD tinderbox has been orange for the last week or so.

Browsing the bugzilla database, this looks related to #4270 and #4275, but with some differences: 1. It's not random. This happens *deterministically* if libucvja.so's mtime is modified and the registry exists. I've tested it five or six times, and it's happened every time. 2. I don't have any sort of multi-processor machine. My computer is a single-processor P-II/400. Maybe there's something about FreeBSD (maybe its threading model? I've compiled with pthreads) which always triggers the race condition, if that's what it is?

Setting summary (please improve if you can). /be

So is it that the core dump happens every time after libucvja.so changes and not just on first launch after libucvja.so changes

No, the crash is only the first time after libucvja.so has changed. I.e.: rm ~/.mozilla/registry [so we're starting from scratch] ./mozilla-apprunner.sh [run sucessfully] touch components/libucvja.so ./mozilla-apprunner.sh MOZILLA_FIVE_HOME=/home/llennox/Mozilla/mozilla/dist/bin LD_LIBRARY_PATH=/home/llennox/Mozilla/mozilla/dist/bin MOZ_PROGRAM=apprunner nsComponentManager: Using components dir: /home/llennox/Mozilla/mozilla/dist/bin/components Bus error - core dumped ./mozilla-apprunner.sh [run sucessfully] Oddly, when I try to trace through this in gdb, the bus error occurs during the component registration of a *different* library (libucvlatin.so). Here's the stack trace: (gdb) run Starting program: /home/llennox/Mozilla/mozilla/dist/bin/apprunner nsComponentManager: Using components dir: /home/llennox/Mozilla/mozilla/dist/bin/components Program received signal SIGBUS, Bus error. 0x280817b6 in nsID::Equals (this=0x8069be0, other=@0xfffffffc) at ../../../dist/include/nsID.h:57 57 (((PRUint32*) &m0)[3] == ((PRUint32*) &other.m0)[3])); (gdb) bt #0 0x280817b6 in nsID::Equals (this=0x8069be0, other=@0xfffffffc) at ../../../dist/include/nsID.h:57 #1 0x28dc22d3 in NSGetFactory (aServMgr=0x80542b0, aClass=@0x8069be0, aClassName=0x0, aProgID=0x0, aFactory=0xefbfd150) at nsUCvLatinDll.cpp:623 #2 0x2809a7ad in nsComponentManagerImpl::LoadFactory (this=0x8067080, aEntry=0x8069be0, aFactory=0xefbfd150) at nsComponentManager.cpp:878 #3 0x2809aa09 in nsComponentManagerImpl::FindFactory (this=0x8067080, aClass=@0x804bddc, aFactory=0xefbfd150) at nsComponentManager.cpp:954 #4 0x2809b2b1 in nsComponentManagerImpl::RegisterComponent (this=0x8067080, aClass=@0x804bddc, aClassName=0x0, aProgID=0x0, aLibrary=0x804c386 "libucvlatin.so", aReplace=0, aPersist=0) at nsComponentManager.cpp:1315 #5 0x2809d5ec in nsComponentManager::RegisterComponent (aClass=@0x804bddc, aClassName=0x0, aProgID=0x0, aLibrary=0x804c386 "libucvlatin.so", aReplace=0, aPersist=0) at nsRepository.cpp:108 #6 0x804b2ef in NS_SetupRegistry () at ../../webshell/tests/viewer/nsSetupRegistry.cpp:398 #7 0x804b55d in NS_SetupRegistry_1 () at nsSetupRegistry.cpp:102 #8 0x8049f83 in main (argc=1, argv=0xefbfd2a0) at nsAppRunner.cpp:158 #9 0x8049df5 in _start ()

This could be because of the library has undefined symbols. It should all be fixed now. Can you verify this with the current build ?

registry has changed a lot since then. I haven't gotten a reply on this. Can QA verify this and reopen if this is the case. I can help if there is a machine and a build. I had a similar one in sunos that I tested and it was WORKSFORME.

Adding crash keyword