Loading http://www.crans.ens-cachan.fr/for-mozilla/hale50.jpg correctly loads the jpeg, however, apprunner crashes when loading the page. If the hale50.jpg file is not present, index.html loads correctly. Well, that page includes garbage HTML from FrontPage, but I guess it shouldn't crash. Apprunner doesn't say anything in stdout before dying except "URL to load in nsBrowserAppCore is http://zamok.crans.ens-cachan.fr/for-mozilla" (zsh says "abort ./apprunner") Mozilla : from CVS, about four hours ago. Machine : RedHat 5.2 x86 with linux-2.2.3, egcs-1.1.1, and (since an unrelated HD crash), RedHat 5.9 x86 with linux-2.2.3 and glib-2.1-0.990311, egcs-1.1.2 since.

It doesn't crash for me with viewer under NT

Re-assigned to rickg@netscape.com and changed component to Parser. Rick, this looks like we're not handling the HTML correctly. It doen't really have anything to do with the application shell ...

Here's a stack trace of a crash on apprunner under Linux (this is a fresh tree as of 06-Apr-99 10:15PM: #0 0x406f247b in nsParser::ResumeParse (this=0x816e568, aDefaultDTD=0x0) at nsParser.cpp:787 #1 0x406f1b65 in nsParser::EnableParser (this=0x816e568, aState=1) at nsParser.cpp:518 #2 0x40e2ec6c in XULContentSinkImpl::DoneLoadingStyle (aLoader=0x81b6230, aData=@0x81b6250, aRef=0x81b61e0, aStatus=0) at nsXULContentSink.cpp:648 #3 0x40288363 in nsUnicharStreamLoader::OnStopBinding (this=0x81b6230, aURL=0x81b41b8, aStatus=0, aMsg=0xbffff304) at nsNetStreamLoader.cpp:156 #4 0x402aaa24 in nsDocumentBindInfo::OnStopBinding (this=0x81b6268, aURL=0x81b41b8, aStatus=0, aMsg=0xbffff304) at nsDocLoader.cpp:1989 #5 0x4028b7ca in stub_complete (stream=0x81b6958) at nsStubContext.cpp:585 #6 0x4019ba12 in net_ProcessFile (cur_entry=0x81b6610) at mkfile.c:1356 #7 0x4025b72e in NET_ProcessNet (ready_fd=0x0, fd_type=1) at mkgeturl.c:3312 #8 0x40263795 in NET_PollSockets () at mkselect.c:298 #9 0x40284f92 in nsNetlibService::NetPollSocketsCallback (aTimer=0x81b1db8, aClosure=0x80fd470) at nsNetService.cpp:1277 #10 0x40163025 in TimerImpl::FireTimeout (this=0x81b1db8) at nsTimer.cpp:73 #11 0x40163512 in nsTimerExpired (aCallData=0x81b1db8) at nsTimer.cpp:189 #12 0x40aa4243 in g_timeout_dispatch (source_data=0x81b0a20, current_time=0xbffff7b0, user_data=0x81b1db8) at gmain.c:1144 #13 0x40aa3576 in g_main_dispatch (current_time=0xbffff7b0) at gmain.c:644 #14 0x40aa3ab1 in g_main_iterate (block=1, dispatch=1) at gmain.c:851 #15 0x40aa3c29 in g_main_run (loop=0x81517b8) at gmain.c:909

This appears to be crashing in XUL. My guess is that you're loading a stylesheet, but not refcounting the right objects and you're dying when an object you need goes away. Talk to Waterson.

reassigning to hyatt as p2 for m4, although if this is not a widespread crash you can move it to m5.

Waterson and I looked at this for a while today and wondered if it had to do with a stream that we release inr our XUL content sink that doesn't get released over in the XML content sink. If this stream were to be released too soon (because of a refcount that was one too small), then depending on timing, you might lose it and end up with garbage. CC'ing waterson.

I can't reproduce this crash. Is it still happening?

Marking works for me.

Workd fine with the April 13th Build.

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.