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

File transport thread crashes in page-loader, but browser keeps on ticking

VERIFIED FIXED

Status

()

Core
Networking: File
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: John Morrison, Assigned: dougt)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
As I mentioned to darin today, a couple of times in the past few weeks, while
running the page loading test on win98, a GPF dialog and talkback came up while 
the test was run.

The bizarre thing is that the test continued to run, and completed with no 
apparent degradation in loading times, despite the fact that this crash had 
occurred on one of the threads. The UI was still usable, and content was 
downloaded and displayed correctly the whole time.

Reproducing this will likely be difficult, but perhaps there is a clue in the 
stack trace from talkback. This happened on win98 for Build ID 2001052313 and
Build ID 2001060606. (Note: another similar crash that paw and I were 
mentioning to darin (meta refresh overnight to home.netscape.com or 
www.nytimes.com) turns out to have a different stack, and is a thread crash
on the nsSocketTransport; separate bug to follow).



MSVCRT.DLL + 0x1648 (0x78001648)
CopyChars1To1 [d:\builds\seamonkey\mozilla\string\obsolete\bufferRoutines.h, 
line 245]
nsStr::StrAppend [d:\builds\seamonkey\mozilla\string\obsolete\nsStr.cpp, line 
185]
nsStr::GrowCapacity [d:\builds\seamonkey\mozilla\string\obsolete\nsStr.cpp, 
line 137]
nsCString::SetCapacity 
[d:\builds\seamonkey\mozilla\string\obsolete\nsString.cpp, line 214]
nsString::SetLength [d:\builds\seamonkey\mozilla\string\obsolete\nsString2.cpp, 
line 198]
nsACString::do_AssignFromReadable 
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 713]
nsAString::AssignFromReadable 
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 658]
nsLocalFile::ResolveAndStat 
[d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp, line 522]
nsLocalFile::Exists [d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp, 
line 1543]
nsFileIO::Open [d:\builds\seamonkey\mozilla\netwerk\base\src\nsFileStreams.cpp, 
line 145]
nsFileTransport::Process 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsFileTransport.cpp, line 643]
(Assignee)

Comment 1

17 years ago
This looks like a race condition that I have already fixed.  I check the fix
into the TRUNK yesterday.  Please reopen if you see this problem after todays build.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 2

17 years ago
Sounds good. If I see it again, I will reopen.

Comment 3

16 years ago
VERIFIED:
mozilla 0.9.4 and no reports of this. 

Looked like bug 80013, but I'm not expert here...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.