Closed Bug 13154 Opened 21 years ago Closed 20 years ago
BSD 3 .x: Apprunner crash on startup
I pulled Friday's last-known-good Apprunner (MOZ_CO_DATE="09/03/1999 14:59:32 PDT") and compiled it on FreeBSD 3.2-RELEASE with egcs 1.1.2, and it crashes on startup. Here's a log of what happens when it runs, and a backtrace in gdb: bash-2.02$ ./mozilla-apprunner.sh MOZILLA_FIVE_HOME=/local/llennox/Mozilla/mozilla/dist/bin LD_LIBRARY_PATH=/local/llennox/Mozilla/mozilla/dist/bin MOZ_PROGRAM=./apprunner MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsNativeComponentLoader: autoregistering /local/llennox/Mozilla/mozilla/dist/bin/components nsNativeComponentLoader: autoregistering succeeded GFX: dpi=100 t2p=0.0694444 p2t=14.4 depth=24 Using '/local/llennox/Mozilla/mozilla/dist/bin' as the resource: base NS_NewConverterStream failed Segmentation fault - core dumped bash-2.02$ gdb apprunner GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (gdb) core-file apprunner.core Core was generated by `apprunner'. Program terminated with signal 11, Segmentation fault. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libraptorgfx.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libmozjs.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libxpcom.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libplds3.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libplc3.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libnspr3.so... done. Reading symbols from /usr/X11R6/lib/libgtk12.so.1...done. Reading symbols from /usr/X11R6/lib/libgdk12.so.1...done. Reading symbols from /usr/local/lib/libgmodule12.so.1...done. Reading symbols from /usr/local/lib/libglib12.so.1...done. Reading symbols from /usr/local/lib/libintl.so.1...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/lib/libutil.so.2...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libc_r.so.3...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libnsappshell.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libjsdom.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libappcores.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libchardet.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libwidget_gtk.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libraptorhtmlpars.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libpref.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libsecfree.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/librdf.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libnecko.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libchrome.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libgfx_gtk.so... done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libraptorwebwidget.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/libraptorplugin.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libconverters.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libhistory.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libprofile.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libnecko_file.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libraptorhtml.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libuconv.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libnecko_resource.so...done. Reading symbols from /local/llennox/Mozilla/mozilla/dist/bin/components/libunicharutil.so...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x281a8de6 in nsDll::Load (this=0x805aa80) at xcDll.cpp:260 260 nsresult rv = m_dllSpec->GetNSPRPath(&nsprPath); (gdb) print m_dllSpec $1 = (nsIFileSpec *) 0x0 (gdb) bt #0 0x281a8de6 in nsDll::Load (this=0x805aa80) at xcDll.cpp:260 #1 0x281a24bd in nsNativeComponentLoader::GetFactory (this=0x80512e0, aCID=@0x80718e0, aLocation=0x806d540 "rel:libucvko.so", aType=0x8071900 "application/x-mozilla-native", _retval=0xbfbfccd0) at nsNativeComponentLoader.cpp:121 #2 0x281d3b8e in nsFactoryEntry::GetFactory (this=0x80718e0, aFactory=0xbfbfccd0) at nsComponentManager.h:297 #3 0x2819f875 in nsComponentManagerImpl::FindFactory (this=0x805a100, aClass=@0x812fd80, aFactory=0xbfbfccd0) at nsComponentManager.cpp:1027 #4 0x2819fd9e in nsComponentManagerImpl::CreateInstance (this=0x805a100, aClass=@0x812fd80, aDelegate=0x0, aIID=@0x281da980, aResult=0xbfbfcd7c) at nsComponentManager.cpp:1198 #5 0x281a6f14 in nsComponentManager::CreateInstance (aClass=@0x812fd80, aDelegate=0x0, aIID=@0x281da980, aResult=0xbfbfcd7c) at nsRepository.cpp:77 #6 0x28fb3614 in nsCharsetConverterManager::GetCharsetConverter ( this=0x8124740, aSrc=0x81417d4, aResult=0xbfbfcd7c, aCID=0x281da980, aArray=0x8130804, aSize=57) at nsCharsetConverterManager.cpp:414 #7 0x28fb374b in nsCharsetConverterManager::GetUnicodeDecoder ( this=0x8124740, aSrc=0x81417d4, aResult=0xbfbfcd7c) at nsCharsetConverterManager.cpp:455 #8 0x2872efa4 in nsScanner::SetDocumentCharset (this=0x8141780, aCharset=@0x810d86c, aSource=kCharsetFromDocTypeDefault) at nsScanner.cpp:159 #9 0x2872ed00 in nsScanner::nsScanner (this=0x8141780, aFilename=@0xbfbfce44, aCreateStream=0, aCharset=@0x810d86c, aSource=kCharsetFromDocTypeDefault) at nsScanner.cpp:89 #10 0x2872c5d3 in nsParser::Parse (this=0x810d800, aURL=0x8133640, aListener=0x0, aVerifyEnabled=0, aKey=0x0, aMode=eParseMode_autodetect) at nsParser.cpp:673 #11 0x28801b34 in RDFXMLDataSourceImpl::Refresh (this=0x81332c0, aBlocking=1) at nsRDFXMLDataSource.cpp:921 #12 0x289ce977 in nsChromeRegistry::InitRegistry (this=0x81081b0) at nsChromeRegistry.cpp:613 #13 0x289cfca9 in nsChromeProtocolHandler::NewChannel (this=0x81284d0, verb=0x28095cdd "load", uri=0x8111f80, aGroup=0x8111c80, eventSinkGetter=0x8108180, result=0xbfbfd188) at nsChromeProtocolHandler.cpp:152 #14 0x288aada4 in nsIOService::NewChannelFromURI (this=0x8110460, verb=0x28095cdd "load", aURI=0x8111f80, aGroup=0x8111c80, eventSinkGetter=0x8108180, result=0xbfbfd1d4) at nsIOService.cpp:229 #15 0x2808f985 in NS_OpenURI (result=0xbfbfd250, uri=0x8111f80, aGroup=0x8111c80, eventSinkGetter=0x8108180) at nsNeckoUtil.cpp:63 #16 0x28a1031a in nsDocumentBindInfo::Bind (this=0x8111f00, aURL=0x8111f80, aListener=0x0, postDataStream=0x0) at nsDocLoader.cpp:1814 #17 0x28a0ffec in nsDocumentBindInfo::Bind (this=0x8111f00, aURLSpec=@0xbfbfd79c, aPostDataStream=0x0, aListener=0x0) at nsDocLoader.cpp:1739 #18 0x28a0ea77 in nsDocLoaderImpl::LoadDocument (this=0x8111c00, aURLSpec=@0xbfbfd79c, aCommand=0x28a221e8 "view", aContainer=0x80ffe00, aPostDataStream=0x0, aExtraInfo=0x0, anObserver=0x0, aType=0, aLocalIP=0) at nsDocLoader.cpp:726 #19 0x28a16c14 in nsWebShell::DoLoadURL (this=0x80ffe00, aUrlSpec=@0xbfbfd79c, aCommand=0x28a221e8 "view", aPostDataStream=0x0, aType=0, aLocalIP=0) at nsWebShell.cpp:2219 #20 0x28a1795c in nsWebShell::LoadURL (this=0x80ffe00, aURLSpec=0x8105c00, aCommand=0x28a221e8 "view", aPostDataStream=0x0, aModifyHistory=1, aType=0, aLocalIP=0, aHistoryState=0x0) at nsWebShell.cpp:2436 #21 0x28a15cc9 in nsWebShell::LoadURL (this=0x80ffe00, aURLSpec=0x8105c00, aPostDataStream=0x0, aModifyHistory=1, aType=0, aLocalIP=0, aHistoryState=0x0) at nsWebShell.cpp:2003 #22 0x28535f2e in nsWebShellWindow::Initialize (this=0x8105100, aParent=0x0, aShell=0x80a6b80, aUrl=0x8111380, aCreatedVisible=0, aLoadDefaultPage=0, anObserver=0x0, aCallbacks=0x0, aInitialWidth=100, aInitialHeight=100, widgetInitData=@0xbfbfd9b8) at nsWebShellWindow.cpp:440 #23 0x28534dfe in nsAppShellService::JustCreateTopWindow (this=0x80a6980, aParent=0x0, aUrl=0x8111380, aShowWindow=0, aLoadDefaultPage=0, aChromeMask=2046, aCallbacks=0x0, aInitialWidth=100, aInitialHeight=100, aResult=0xbfbfda10) at nsAppShellService.cpp:585 #24 0x2853421c in nsAppShellService::CreateHiddenWindow (this=0x80a6980) at nsAppShellService.cpp:272 #25 0x2853416f in nsAppShellService::Initialize (this=0x80a6980, aCmdLineService=0x805a640) at nsAppShellService.cpp:252 #26 0x804b7fc in main1 (argc=1, argv=0xbfbfdb78) at nsAppRunner.cpp:787 #27 0x804bbc1 in main (argc=1, argv=0xbfbfdb78) at nsAppRunner.cpp:852 (gdb) The proximate cause of the crash is clear (the fact that m_dllSpec is null) but the broader cause isn't, at least to me.
MOZ_CO_DATE="Mon Sep 6 11:21:54 CEST 1999" on FreeBSD-4.0-CURRENT Apprunner starts and runs without problems.
OK, I'm gonna mark this WORKSFORME if daeron sez it's working for him.
The FreeBSD tinderbox on the ports page is also orange, I'd guess it's the same problem. I've added briano as a Cc: since he's the port owner...can you see if it's the same problem I was reporting here?
Status: RESOLVED → REOPENED
Summary: FreeBSD: Apprunner crash on startup → FreeBSD 3.x: Apprunner crash on startup
I've reopened this, since I'm seeing the same symptoms with today's build. I think FreeBSD 3.2-RELEASE and 4.0-CURRENT are behaving differently here. (I've changed the bug's summary line accordingly.) After a bit more investigation, it looks like this is actually three different crashes, and one case where Apprunner will start correctly. Crash 1: initial start, ~/.mozilla doesn't exist, mozilla/dist/bin/component.reg doesn't exist: (gdb) run Starting program: /local/llennox/Mozilla/mozilla/dist/bin/./apprunner nsNativeComponentLoader: autoregistering /local/llennox/Mozilla/mozilla/dist/bin/components Program received signal SIGBUS, Bus error. (gdb) bt #0 nsIDKey::nsIDKey (this=0xbfbfccb4, aID=@0xfffffffc) at ../../../../dist/include/nsHashtable.h:173 #1 0x281a1387 in nsComponentManagerImpl::RegisterComponentCommon ( this=0x805a100, aClass=@0xfffffffc, aClassName=0xbfbfce14 "Unicode Encoder-\203D$\004üSè", aProgID=0xbfbfcd94 "component://netscape/intl/unicode/encoder?charset=\203D$\004üSè", aRegistryName=0x80655c0 "rel:libucvlatin.so", aReplace=1, aPersist=1, aType=0x281dc7a0 "application/x-mozilla-native") at nsComponentManager.cpp:1511 #2 0x281a11db in nsComponentManagerImpl::RegisterComponent (this=0x805a100, aClass=@0xfffffffc, aClassName=0xbfbfce14 "Unicode Encoder-\203D$\004üSè", aProgID=0xbfbfcd94 "component://netscape/intl/unicode/encoder?charset=\203D$\004üSè", aPersistentDescriptor=0x8065160 "rel:libucvlatin.so", aReplace=1, aPersist=1) at nsComponentManager.cpp:1426 ... I think this crash is what is turning the FreeBSD tinderbox orange. Next: immediately re-run, after previous crash: *success*. A whole bunch of components register, and then the profile wizard pops up; once a profile has been created, apprunner runs happily. Crash #2: quit apprunner, and restart it. we get the crash I described in the original bug report. This is now a steady state, crashing every time, unless files are deleted manually. Crash #3: delete component.reg, but *not* ~/.mozilla. In this case, we crash shortly after the "Calling gdk_input_add with event queue" debug message is printed: (gdb) down 15 #0 0x28baf5a5 in nsUnicharStreamLoader::OnDataAvailable (this=0x8407d60, channel=0x840c200, ctxt=0x0, inStr=0x0, sourceOffset=0, count=32768) at nsNetStreamLoader.cpp:175 175 inStr->GetLength(&len); (gdb) print inStr $1 = (nsIInputStream *) 0x0 (gdb) bt #0 0x28baf5a5 in nsUnicharStreamLoader::OnDataAvailable (this=0x8407d60, channel=0x840c200, ctxt=0x0, inStr=0x0, sourceOffset=0, count=32768) at nsNetStreamLoader.cpp:175 #1 0x2937105c in nsChannelListener::OnDataAvailable (this=0x83f5c90, aChannel=0x840c200, aContext=0x0, aInStream=0x0, aOffset=0, aCount=32768) at nsDocLoader.cpp:2476 #2 0x294a2d2c in nsFileChannel::OnDataAvailable (this=0x840c200, channel=0x840c200, context=0x0, aIStream=0x0, aSourceOffset=0, aLength=32768) at nsFileChannel.cpp:807 #3 0x29737a2b in nsOnDataAvailableEvent::HandleEvent (this=0x82f1040) at nsAsyncStreamListener.cpp:344 #4 0x2973727f in nsStreamListenerEvent::HandlePLEvent (aEvent=0x82f1040) at nsAsyncStreamListener.cpp:144 So we have three separate crashes, none of which occur on FreeBSD 4.0-CURRENT. My suspicion is that this has something to do with DSO loading, and that bug 6323 is related, since it similarly has the symptom of not occuring on FreeBSD 4.0-CURRENT (or Linux), and seems to have something to do with the shared libraries. Are there any other FreeBSD 3.x people out there?
Clearing WorksForMe resolution due to reopen. cyeh, who should get this bug?
assigned to briano
I'm checking in a fix that ought to resolve the following crash: #0 0x281a8de6 in nsDll::Load (this=0x805aa80) at xcDll.cpp:260 #1 0x281a24bd in nsNativeComponentLoader::GetFactory (this=0x80512e0, aCID=@0x80718e0, aLocation=0x806d540 "rel:libucvko.so", aType=0x8071900 "application/x-mozilla-native", _retval=0xbfbfccd0) at nsNativeComponentLoader.cpp:121 #2 0x281d3b8e in nsFactoryEntry::GetFactory (this=0x80718e0, aFactory=0xbfbfccd0) at nsComponentManager.h:297 #3 0x2819f875 in nsComponentManagerImpl::FindFactory (this=0x805a100, aClass=@0x812fd80, aFactory=0xbfbfccd0) at nsComponentManager.cpp:1027 #4 0x2819fd9e in nsComponentManagerImpl::CreateInstance (this=0x805a100, aClass=@0x812fd80, aDelegate=0x0, aIID=@0x281da980, aResult=0xbfbfcd7c) at nsComponentManager.cpp:1198 It still crashes for me, but I'll keep on it.
As of the 1999-09-13 morning build, the nsDll::Load crash is gone, but I'm still seeing the nsIDKey::nsIDKey and the nsUnicharStreamLoader::OnDataAvailable crashes. Also, the case which got a working apprunner before (second run after deleting component.reg and ~/.mozilla) no longer does; I always see the nsIDKey crash if component.reg doesn't exist, or nsUnicharStreamLoader if it does.
Okay, I've gotten a diagnosis of what's going on in the first crash -- the nsIDKey crash -- and it's a sufficiently insidious problem that I suspect if it's fairly general it could be the cause of all the other startup crashes, and the PNG/JPEG problems, as well. See the gdb log I've included as an attachment (right after this comment). Notice that the components being registered for all the Unicode converters all have names involving Japanese character sets, even for libucvcn.so and libucvlatin.so (which should be Chinese and European respectively). The problem is occuring because the symbol g_FactoryData exists in all the uconv libraries; for some reason, RegisterSelf in libucvcn and libucvlatin is picking up the g_FactoryData definition from libucvja. The crash, specifically, is occuring because the size of the array is computed at compile time, and g_FactoryData is longer in nsUCvLatinDll.cpp than in nsUCvJADll.cpp, so libucvlatin.so's RegisterSelf is walking off the end of the (wrong) array and catching a SIGBUS. Symbol names are repeated between enough different components that if this bug is "symbols are resolved to the first symbol loaded with that name, rather than the one in this DSO," it will wreak havoc on Mozilla -- as indeed seems to be happening. Does this help anyone enough so as to track down what might be going wrong? I wish I knew when precisely this bug was introduced.
This is potentially serious and has wide-spread implications, so I'm cc'ing some appropriate high-level thinkers to help get the word out.
frank/dp, can you comment on this bug?
Please try the following and let me know does it help: 1. Change all the *Dll.cpp in mozilla/intl/uconv/ucv* 2. change the line FontFactory g_FactoryData= to static FontFactory g_FactoryData= rebuild intl/uconv/
Yep, that clears up the nsIDKey / uconv crash, and a gdb trace shows that the uconv libraries are registering properly. I now crash in nsUnicharStreamLoader::OnDataAvailable, as above. Still, it seems very strange to me that FreeBSD should have this problem, when none of the other platforms do; it implies to me that there's something wrong with components on FreeBSD. Non-exported symbols are supposed to be component-local, right?
bug 13030 could realted to this. add firstname.lastname@example.org to the CC. Could you do a nm ucvlatin.so|egrep g_FactoryData in the build that you didn't put the static ? What do you see ? My linux build show nothing but I guess you will see something there... I will add static to all the *Dll.cpp But I think the problem have to be fixed in the configuration file. Braino, any clue ?
bash-2.02$ nm libucvlatin.so|egrep g_FactoryData 0002d4e0 D g_FactoryData The 'static' patch changes the 'D' to 'd', i.e. the symbol isn't extern any more. It really doesn't show up in 'nm' at all on Linux? g_InstanceCount, g_LockCount, and g_ASCIIMapping are similarly defined in multiple uconv components, but I got error messages when I tried to declare those static.
Just discovered: configuring with --enable-low-fat also cures the nsIDKey / uconv crash, since it uses gnu ld tricks to mark all symbols unexported. (This has nasty side effects though, namely spewing "Ignored d_tag " messages. I'll file another bug report on this.) After this, I can get apprunner to start, *if* (this one mystifies me) I run under gdb, and set a breakpoint at dlopen(). The breakpoint never triggers, but somehow this avoids the onDataAvailable crash... Apprunner looks *very* different when compiled this way, too -- it's like night and day. Before, gfx textboxes were mangled, the sidebar wasn't working...I hadn't realized how functional Mozilla was by now.
I checkin the change to make all g_FactoryData as static. But it should not be the real problem. Right. No nm display nothing to me if I type bash-2.02$ nm libucvlatin.so|egrep g_FactoryData 0002d4e0 D g_FactoryData Not even with D. No you cannot make other symbol static since they are not true file private. This g_FactoryData is true file private. Should we consider this bug closed ?
No, the component issues and the other crashes are still open. I think the i18n part of it is resolved, though.
Is that true this is a compiling/build configuration issue instead of a component issue ?
mass reassigning briano's open bugs to me while he's on sabbatical.
mass move to M14.
Updating QA Contact/component.
http://bugzilla.mozilla.org/show_bug.cgi?id=20857 is probably related to this..?
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 14676 ***
verified duplicate of 14676 ('dlopen() bug in FreeBSD 3.x causes problems with components')
You need to log in before you can comment on or make changes to this bug.