I've tried the csv version of mozilla the last few weeks up to today july 22 1999 and all fail in the same way. Mozilla compiled with './configure --disable-md && make depend && make' (the compiler assisted depends segfault egcs) $ g++ --version egcs-2.91.66 $ gtk-config --version 1.2.3 What else can i tell, libc5 a backtrace... #0 0x408593c5 in __kill () #1 0x4084239d in raise (sig=1081353830) #2 0x407609d6 in g_log (log_domain=0x40742666 "Gdk", log_level=G_LOG_LEVEL_ERROR, format=0x4074273d "an x io error occurred") at gmessages.c:406 #3 0x40723725 in gdk_x_io_error (display=0x80a2508) at gdk.c:1077 #4 0x407b367f in _XIOError () #5 0x407b1763 in _XRead () #6 0x407b1fc7 in _XReply () #7 0x4079d6bb in _XQueryFont () #8 0x4079d538 in XLoadQueryFont () #9 0x4072fe0b in gdk_font_load ( font_name=0x8111828 "-adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1") at gdkfont.c:41 #10 0x400d2770 in nsFontGTK::LoadFont (this=0x81118e8, aCharSet=0x8110510, aMetrics=0x810d6b0) at nsFontMetricsGTK.cpp:1233 #11 0x400d2984 in PickASizeAndLoad (aSearch=0xbffff4b4, aStretch=0x8110c40, aCharSet=0x8110510) at nsFontMetricsGTK.cpp:1289 #12 0x400d3a8a in TryCharSet (aSearch=0xbffff4b4, aCharSet=0x8110510) at nsFontMetricsGTK.cpp:1715 #13 0x400d3b65 in SearchCharSet (he=0x8110528, i=0, arg=0xbffff4b4) at nsFontMetricsGTK.cpp:1740 #14 0x405ac201 in PL_HashTableEnumerateEntries (ht=0x81104a0, f=0x400d3a94 <SearchCharSet(PLHashEntry *, int, void *)>, arg=0xbffff4b4) at plhash.c:368 #15 0x400d3bb8 in TryFamily (aSearch=0xbffff4b4, aFamily=0x810e790) at nsFontMetricsGTK.cpp:1754 #16 0x400d5561 in nsFontMetricsGTK::FindFont (this=0x810d6b0, aChar=97) at nsFontMetricsGTK.cpp:2097 #17 0x400d16dd in nsFontMetricsGTK::Init (this=0x810d6b0, aFont=@0xbffff730, aContext=0x810c650) at nsFontMetricsGTK.cpp:156 #18 0x400b2850 in nsFontCache::GetMetricsFor (this=0x810d678, aFont=@0xbffff730, aMetrics=@0xbffff5b8) at nsDeviceContext.cpp:678 #19 0x400b173d in DeviceContextImpl::GetMetricsFor (this=0x810c650, aFont=@0xbffff730, aMetrics=@0xbffff5b8) at nsDeviceContext.cpp:244 #20 0x40074047 in nsWidget::SetFont (this=0x810c590, aFont=@0xbffff730) at nsWidget.cpp:443 #21 0x40060e6c in NS_CreateButton (aParent=0x80efda0, aButton=0x810c620, aRect=@0xbffff714, aHandleEventFunction=0x805739c <HandleBackEvent(nsGUIEvent *)>, aFont=0xbffff730) at nsWidgetSupport.cpp:71 #22 0x805abd3 in nsBrowserWindow::CreateToolBar (this=0x80efbe0, aWidth=620) at nsBrowserWindow.cpp:1328 #23 0x805a2ad in nsBrowserWindow::Init (this=0x80efbe0, aAppShell=0x8077d98, aPrefs=0x80bbba8, aBounds=@0xbffffa74, aChromeMask=4294967295, aAllowPlugins=1) at nsBrowserWindow.cpp:1171 #24 0x8063228 in nsViewerApp::OpenWindow (this=0x8075270) at nsViewerApp.cpp:581 #25 0x8051b27 in nsNativeViewerApp::Run (this=0x8075270) at nsGTKMain.cpp:41 #26 0x8051d5b in main (argc=1, argv=0xbffffafc) at nsGTKMain.cpp:89 #27 0x80519ce in _start ()

Cc'ing the guys who know this code intimately, and will know what to do about this.

What OS? We had a font problem yesterday that got fixed. Try again?

No change using today's version 2 aug 1999. The adresses differ obviously but bt functions are the same, so is the error. OS == Linux 2.0.37, libc5,

resummarizing.

What development work is this blocking? If it is a real blocker, it should be p1 for M9.

Adding status whiteboard comment.

general browser, m10. fhc, is this still happening? I don't have a libc5 machine to test this on, but I have seen solaris crash like this. Not a blocker, over to leger for QA contact reassignment.

Yes, got the csv version today (11/8/99) and this is still happening.

m11

Solaris in m12 for me.

This isn't happening on systems here. Can you try another account? Eliminate any special fonts? Is this a Dutch system by any chance?

Move to M13 until we can repro this.

giving me rest of phillips open qa contact bugs, sorry for spam

Worry about this in M15.

can you run mozilla-bin with --sync to make sure it is actually crashing in font loading code and not somewhere else? if this is crashing then we probably need some kind of resolution for beta and shouldn't push it to m15

Adding "crash" keyword to all known open crasher bugs.

*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to jrgm@netscape.com

Chris, is this still a big beta 2 issue?

I asked the reporter if this is still a problem. Quoted from the answer: Still dumps core on start up no longer in the font code though, i'm using a rather old install here, libc5 etc. dunno if this is relevant. included is a bt. #0 0x405216ee in strlen (str=0x8137578 "") #1 0x4085c0d8 in nsScriptSecurityManager::nsIXPCSecurityManager virtual table () #2 0x405fec83 in XPCConvert::NativeData2JS (cx=0x8137578, d=0xbfffefc4, s=0xbffff088, type=@0xbfffefd7, iid=0x0, scope=0x81071a0, pErr=0xbffff060) at xpcconvert.cpp:356 #3 0x406186f3 in nsXPCWrappedNativeClass::CallWrappedMethod (this=0x80f6500, cx=0x8137578, wrapper=0x81532c0, desc=0x81531e4, callMode=CALL_METHOD, argc=0, argv=0x0, vp=0xbffff234) at xpcwrappednativeclass.cpp:984 #4 0x4061a177 in WrappedNative_Convert (cx=0x8137578, obj=0x81071a0, type=JSTYPE_STRING, vp=0xbffff234) at xpcwrappednativejsops.cpp:136 #5 0x4061b845 in WrappedNative_DefaultValue (cx=0x8137578, obj=0x81071a0, type=JSTYPE_STRING, vp=0xbffff234) at xpcwrappednativejsops.cpp:511 #6 0x400f27eb in js_ValueToString (cx=0x8137578, v=0) at jsstr.c:2286 #7 0x400a66ba in js_ReportUncaughtException (cx=0x8137578) at jsexn.c:645 #8 0x4008825e in JS_ExecuteScript (cx=0x8137578, obj=0x8106fc8, script=0x815b7c8, rval=0xbffff340) at jsapi.c:2661 #9 0x4082634f in mozJSComponentLoader::GlobalForLocation (this=0x814f720, aLocation=0x816e2d8 "rel:nsSample.js", component=0x8154300) at mozJSComponentLoader.cpp:841 #10 0x4082594a in mozJSComponentLoader::ModuleForLocation (this=0x814f720, registryLocation=0x816e2d8 "rel:nsSample.js", component=0x8154300) at mozJSComponentLoader.cpp:698 #11 0x40825442 in mozJSComponentLoader::AttemptRegistration (this=0x814f720, component=0x8154300, deferred=0) at mozJSComponentLoader.cpp:581 #12 0x40825124 in mozJSComponentLoader::AutoRegisterComponent (this=0x814f720, when=0, component=0x8154300, registered=0xbffff5f0) at mozJSComponentLoader.cpp:511 #13 0x40824968 in mozJSComponentLoader::RegisterComponentsInDir (this=0x814f720, when=0, dir=0x814f988) at mozJSComponentLoader.cpp:391 #14 0x408246c0 in mozJSComponentLoader::AutoRegisterComponents (this=0x814f720, when=0, aDirectory=0x814f988) at mozJSComponentLoader.cpp:347 #15 0x401b094a in AutoRegister_enumerate (key=0x8138348, aData=0x814f720, aClosure=0xbffff830) at nsComponentManager.cpp:1909 #16 0x401722fd in _hashEnumerate (he=0x81677a0, i=0, arg=0xbffff740) at nsHashtable.cpp:89 #17 0x40258a58 in PL_HashTableEnumerateEntries (ht=0x809cc60, f=0x401722c4 <_hashEnumerate(PLHashEntry *, int, void *)>, arg=0xbffff740) at plhash.c:368 #18 0x40172863 in nsHashtable::Enumerate (this=0x809cc50, aEnumFunc=0x401b08bc <AutoRegister_enumerate(nsHashKey *, void *, void *)>, closure=0xbffff830) at nsHashtable.cpp:218 #19 0x401b11b6 in nsComponentManagerImpl::AutoRegister (this=0x80998b8, when=0, inDirSpec=0x0) at nsComponentManager.cpp:2005 #20 0x401b9b08 in nsComponentManager::AutoRegister (when=0, directory=0x0) at nsRepository.cpp:200 #21 0x8072983 in nsViewerApp::AutoregisterComponents (this=0x8137f30) at nsViewerApp.cpp:258 #22 0x80729bd in nsViewerApp::SetupRegistry (this=0x8137f30) at nsViewerApp.cpp:269 #23 0x8072c88 in nsViewerApp::Initialize (this=0x8137f30, argc=1, argv=0xbffffa5c) at nsViewerApp.cpp:309 #24 0x807dcba in main (argc=1, argv=0xbffffa5c) at nsGtkMain.cpp:172 #25 0x805b61e in _start ()

Move to M21 target milestone.

We can't repro this here. Stack trace is way-different now. Suggest retrying this and/or opening another bug. Please reopen if you can reproduce and can help us reproduce. Marking worskforme.

verified.