Closed Bug 13154 Opened 21 years ago Closed 20 years ago

FreeBSD 3.x: Apprunner crash on startup

Categories

(SeaMonkey :: Build Config, defect, P3, critical)

x86
FreeBSD
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 14676

People

(Reporter: lennox, Assigned: granrosebugs)

Details

Attachments

(1 file)

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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
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?
Assignee: don → cyeh
Status: REOPENED → NEW
Resolution: WORKSFORME → ---
Clearing WorksForMe resolution due to reopen.  cyeh, who should get this bug?
Assignee: cyeh → briano
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.
Status: NEW → ASSIGNED
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 braino@netscape.com 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.
accept bug.
mass move to M14.
Component: Browser-General → Build Config
QA Contact: leger → granrose
Updating QA Contact/component.
http://bugzilla.mozilla.org/show_bug.cgi?id=20857 is probably related to this..?
QA Contact: granrose → cyeh
Status: ASSIGNED → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 14676 ***
Status: RESOLVED → VERIFIED
verified duplicate of 14676 ('dlopen() bug in FreeBSD 3.x causes problems with
components')
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.