If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

apprunner crashes on page load.

VERIFIED WORKSFORME

Status

()

Core
XUL
P2
major
VERIFIED WORKSFORME
19 years ago
9 years ago

People

(Reporter: chepelov, Assigned: David Hyatt)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: troy → don
Component: Layout → Apprunner

Comment 1

19 years ago
It doesn't crash for me with viewer under NT

Updated

19 years ago
Assignee: don → rickg
Component: Apprunner → Parser

Comment 2

19 years ago
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 ...

Comment 3

19 years ago
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

Updated

19 years ago
Assignee: rickg → don

Comment 4

19 years ago
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.

Updated

19 years ago
Assignee: don → trudelle
Component: Parser → XUL

Updated

19 years ago
Assignee: trudelle → hyatt
Priority: P3 → P2
Target Milestone: M4

Comment 5

19 years ago
reassigning to hyatt as p2 for m4, although if this is not a widespread crash you
can move it to m5.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

19 years ago
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.
(Assignee)

Comment 7

19 years ago
I can't reproduce this crash.  Is it still happening?
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 8

19 years ago
Marking works for me.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 9

19 years ago
Workd fine with the April 13th Build.

Comment 10

18 years ago
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: chrispetersen → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.