[CRASH] Repeated clicks on "Sidebar Reload" crashes browser build 1999042808

VERIFIED FIXED in M5

Status

Core Graveyard
Tracking
P1
normal
VERIFIED FIXED
19 years ago
a year ago

People

(Reporter: ssym, Assigned: Chris Waterson)

Tracking

Trunk
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
DESCRIPTION
There is a purple "reload" button in the left-hand side frame....clicking on it
numerous times crashes the browser.

STEPS TO REPRODUCE
1. Start Apprunner, I started it from a DOS box.  Maximise the window it starts
in (it seems to crash more easily when maximised).
2. Drag out your left-hand side frame until you can see the "reload" button
clearly.  Dragging it out more than halfway across the screen is best.
3. Left-Click on this button quickly and repeatedly, for about 10-15
seconds....crashes before 15 seconds usually...

ACTUAL RESULTS
The browser crashes!!  The crash box yields the following info:

<START QUOTE>

APPRUNNER caused an invalid page fault in
module RAPTORHTML.DLL at 0137:00dca6fa.
Registers:
EAX=00000000 CS=0137 EIP=00dca6fa EFLGS=00010246
EBX=01254880 SS=013f ESP=0077f66c EBP=0077f6c4
ECX=01299b10 DS=013f ESI=00d5d308 FS=10ff
EDX=0077f6d0 ES=013f EDI=0129b990 GS=0000
Bytes at CS:EIP:
8b 08 ff 51 3c 8b 45 18 85 c0 74 1d 8b 08 50 ff
Stack dump:
00000000 0077f6d0 0125edb8 0125edb0 00000001 00451a48 0129c7f0 0000000c 00000010
815d7ec4 00000000 30014410 00930d1c 008584a0 00857ea8 00000003

<END QUOTE>

EXPECTED RESULTS
The frame refreshes itself, and ignores all input from the "reload" button until
the refreshing is complete.  No crashes expected =)

BUILD DATE
4/29/1999, Build 1999042808, using Win95 ver 4.00.1111

Updated

19 years ago
Assignee: don → matt
Priority: P3 → P1
Summary: Repeated clicks on "Reload" crashes browser build 1999042808 → [CRASH] Repeated clicks on "Reload" crashes browser build 1999042808
Target Milestone: M5

Comment 1

19 years ago
Matt, any idea what's happening here?

Updated

19 years ago
Assignee: matt → waterson

Comment 2

19 years ago
Looks like it is crsahing in nsXULDocument.cpp
calling nsElementMap in watersons code.
It seems like when i reload the flash.xul
file it is crashing

nsDebug::Error(char * 0x01264b60, char * 0x01264b30, int 335) line 168 + 13
bytes
nsElementMap::Remove(nsIRDFResource * 0x01b75120, nsIContent * 0x01b5c130) line
335 + 21 bytes
XULDocumentImpl::RemoveElementForResource(XULDocumentImpl * const 0x0105bcc4,
nsIRDFResource * 0x01b75120, nsIContent * 0x01b5c130) line 2238
RDFElementImpl::SetDocument(RDFElementImpl * const 0x01b5c130, nsIDocument *
0x00000000, int 1) line 1327 + 79 bytes
RDFElementImpl::SetDocument(RDFElementImpl * const 0x01b598c0, nsIDocument *
0x00000000, int 1) line 1405
RDFElementImpl::SetDocument(RDFElementImpl * const 0x01b53d60, nsIDocument *
0x00000000, int 1) line 1405
RDFElementImpl::SetDocument(RDFElementImpl * const 0x01b39d60, nsIDocument *
0x00000000, int 1) line 1405
XULDocumentImpl::SetScriptContextOwner(nsIScriptContextOwner * 0x00000000) line
1625
DocumentViewerImpl::~DocumentViewerImpl() line 201
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x0105b280) line 153 + 99
bytes
nsWebShell::Destroy(nsWebShell * const 0x01058120) line 894 + 27 bytes


I can take out the functionality for M5 if we want as a easy workaround
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Summary: [CRASH] Repeated clicks on "Reload" crashes browser build 1999042808 → [CRASH] Repeated clicks on "Sidebar Reload" crashes browser build 1999042808
(Assignee)

Comment 3

19 years ago
Created attachment 85 [details]
stack trace
(Assignee)

Updated

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

Comment 4

19 years ago
I am not seeing this crash, but I am seeing an assert: see attached stack
trace.

I fixed some refcounting bugs that were prematurely releasing stuff last night.
Could we please verify in the current build?

With respect to the assert I attached, there is a related problem. I opened
another bug for it: see 5735. This shouldn't cause a crash though.
(Assignee)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Assignee)

Comment 5

19 years ago
Created attachment 88 [details] [diff] [review]
proposed fix
(Assignee)

Comment 6

19 years ago
nsDocumentViewer is not checking return codes! Bad bad bad.

See proposed fix. Nisheeth, can you code review so I can get this checked in?

Comment 7

19 years ago
This is fine.  Please check in.  Thanks.
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: WORKSFORME → FIXED
(Assignee)

Comment 8

19 years ago
Okay, now I REALLY have a fix. The remote-flash-n.rdf files were specifying
"id" in lower case, which was thoroughly confusing the XUL builder. Need to use
ID, per RDF spec.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 9

19 years ago
Marking Verified.

Comment 10

19 years ago
Moving all Apprunner bugs past and present to Other component temporarily whilst
don and I set correct component.  Apprunner component will be deleted/retired
shortly.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.