13154 - FreeBSD 3.x: Apprunner crash on startup

Reporter

Description

•

25 years ago

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.

Pascal Hofstee

Comment 1

•

25 years ago

MOZ_CO_DATE="Mon Sep  6 11:21:54 CEST 1999"

on FreeBSD-4.0-CURRENT Apprunner starts and runs without problems.

don

Updated

•

25 years ago

Status: NEW → RESOLVED

Closed: 25 years ago

Resolution: --- → WORKSFORME

don

Comment 2

•

25 years ago

OK, I'm gonna mark this WORKSFORME if daeron sez it's working for him.

Jonathan Lennox

Reporter

Comment 3

•

25 years ago

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?

Jonathan Lennox

Reporter

Updated

•

25 years ago

Status: RESOLVED → REOPENED

Summary: FreeBSD: Apprunner crash on startup → FreeBSD 3.x: Apprunner crash on startup

Jonathan Lennox

Reporter

Comment 4

•

25 years ago

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?

leger

Updated

•

25 years ago

Assignee: don → cyeh

Status: REOPENED → NEW

leger

Updated

•

25 years ago

Resolution: WORKSFORME → ---

leger

Comment 5

•

25 years ago

Clearing WorksForMe resolution due to reopen.  cyeh, who should get this bug?

Chris Yeh

Updated

•

25 years ago

Assignee: cyeh → briano

Chris Yeh

Comment 6

•

25 years ago

assigned to briano

Chris Toshok

Comment 7

•

25 years ago

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.

Jonathan Lennox

Reporter

Comment 8

•

25 years ago

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.

Jonathan Lennox

Reporter

Comment 9

•

25 years ago

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.

Jonathan Lennox

Reporter

Comment 10

•

25 years ago

Attached file GDB log of nsID crash and related problems — Details

Brian Ostrom

Updated

•

25 years ago

Status: NEW → ASSIGNED

Brian Ostrom

Comment 11

•

25 years ago

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.

chris hofmann

Comment 12

•

25 years ago

frank/dp, can you comment on this bug?

Frank Tang

Comment 13

•

25 years ago

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/

Jonathan Lennox

Reporter

Comment 14

•

25 years ago

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?

Frank Tang

Comment 15

•

25 years ago

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 ?

Jonathan Lennox

Reporter

Comment 16

•

25 years ago

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.

Jonathan Lennox

Reporter

Comment 17

•

25 years ago

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.

Frank Tang

Comment 18

•

25 years ago

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 ?

Jonathan Lennox

Reporter

Comment 19

•

25 years ago

No, the component issues and the other crashes are still open.  I think the i18n
part of it is resolved, though.

Frank Tang

Comment 20

•

25 years ago

Is that true this is a compiling/build configuration issue instead of a
component issue ?

Jon Granrose

Assignee

Comment 21

•

25 years ago

mass reassigning briano's open bugs to me while he's on sabbatical.

Jon Granrose

Assignee

Comment 22

•

25 years ago

accept bug.

Jon Granrose

Assignee

Comment 23

•

25 years ago

mass move to M14.

leger

Updated

•

25 years ago

Component: Browser-General → Build Config

QA Contact: leger → granrose

leger

Comment 24

•

25 years ago

Updating QA Contact/component.

Markus Holmberg

Comment 25

•

25 years ago

http://bugzilla.mozilla.org/show_bug.cgi?id=20857 is probably related to this..?

Jon Granrose

Assignee

Updated

•

25 years ago

QA Contact: granrose → cyeh

Markus Holmberg

Updated

•

25 years ago

Status: ASSIGNED → RESOLVED

Closed: 25 years ago → 25 years ago

Resolution: --- → DUPLICATE

Markus Holmberg

Comment 26

•

25 years ago

*** This bug has been marked as a duplicate of 14676 ***

Asa Dotzler [:asa]

Updated

•

25 years ago

Status: RESOLVED → VERIFIED

Asa Dotzler [:asa]

Comment 27

•

25 years ago

verified duplicate of 14676 ('dlopen() bug in FreeBSD 3.x causes problems with
components')

Myk Melez [:myk] [@mykmelez]

Updated

•

20 years ago

Product: Browser → Seamonkey