Closed Bug 102864 Opened 23 years ago Closed 23 years ago

browser crash while loading page - Trunk [@ nsHttpTransaction::Release]

Categories

(Core :: Networking: HTTP, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: aha, Assigned: darin.moz)

References

()

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(4 files)

While loading page, browser makes a crash. (I'm expecting, that HTML of page is
terrible.)

Using:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20011002

Talkbacks:
TB36202960Q
TB36202922Q
TB36202875Q
Also: 
TB36203132E
TB36203096X

On old 2001083103 on Win98 it is okay.
Severity: normal → critical
Keywords: crash
Crashed me as well in 2001100203-trunk on NT4sp6a
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20011002
Talkback didn't trigger; Dr Watson log attached. "Exception: access violation
(0xc0000005), Address: 0x6084aec1"
Oh, and the turbo icon persists in the systray until the mouse pointer actually
goes over it.

Note, however, that 2001093008-trunk and 2001091303-0.9.4 do *not* crash on
either URL given. Regression?
David: Dr Watson log files are unfortunately not very helpful :-(. However,
talkback information is. You can get a talkback-enabled build here:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip

Normally, at this point, I would ask that you try that build and post any
Talkback IDs in this bug. However, Adam has supplied more than enough ;).
BTW I tryed it again after reinstalling Mozilla, problem appears again, browser
crashes, but TalkBack didn't start (I'm using talkback-zipfile). 

Dr. Watson reports:
Exception: hardcoded breakpoint (0x80000003), Address: 0x77f762e8

Second BTW: If anybody confirm this bug, anybody else could make backup of this
page (including ads, iframes, images), because server providing it, is
news-server with very often redesigning.

David Gerard: 
I have experience, that systray icon always stay after application crash (ICQ,
Winamp, ...).
nsHttpTransaction::Release
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpTransaction.cpp,
line 694]
nsHttpChannel::GetStatus
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 1587]
nsRequestObserverProxy::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 230]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072] 
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
QA Contact: doronr → tever
The disassembly doesn't make sense with the stack.  It is a crash with eax as null:

6084aec1 8b08             mov     ecx,[eax]             <== CRASH HERE
6084aec3 ff5138           call    dword ptr [ecx+0x38]
6084aec6 8bd8             mov     ebx,eax
6084aec8 f7c300000080     test    ebx,0x80000000
6084aece 7522             jnz     6084aef2
6084aed0 8b3f             mov     edi,[edi]
6084aed2 8d542410         lea     edx,[esp+0x10]
6084aed6 33c0             xor     eax,eax
6084aed8 52               push    edx
6084aed9 50               push    eax
6084aeda 89442418         mov     [esp+0x18],eax
6084aede 8b0f             mov     ecx,[edi]
darin
Assignee: neeti → darin
David Baron: Though that one talkback doesn't make sense, are any of the other
talkbacks useful?
dbaron: needless to say, that stack trace seems bogus...
nsHttpChannel::GetStatus doesn't release anything.. certainly not a
nsHttpTransaction.
reporter (anyone): i'm having trouble contacting the webserver.  can you please
generate a HTTP log using the following steps:

0) (under winnt) run cmd.exe
1) set NSPR_LOG_MODULES=nsHttp:5
2) set NSPR_LOG_FILE=c:\http.log       <-- or whatever path you like
3) cd <path-to-mozilla-nightly-build>
4) .\mozilla

then just attach the generated http.log file.  this will help me track down the
problem.  thanks in advance!
Adding CC: David Baron, as I think he fell off the CC list when this transferred
over to Darin. (David: Feel free to remove yourself if you no longer want to
participate in this bug)
so, both of these logs correspond to a crash?
Darin: AFAIK. At the very least, I would conjecture that Adam's definitely
corresponds to a crash, since he reported the bug. Likely, though, Matti's does
as well.
adam, matti: do either of you have a debug build?  the http log file is not
telling me much.
Darin: My log is with crash.
Where I could d/l debug build or what I have to enable? (In preferences? In
Debug pop-up menu?)

[I'm sorry for my questions, but I'm just web-developer =)]
Tryed on 2001100303, same crash, generate TB36240815Q (same crash as in
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=52002 attachement).

Is anything else, that could be logged and should help to find problem?
Alex: I was using a talkback build. As I said, Talkback didn't kick in.

Similar to bug 103075 ? No talkback for this bug or that one, despite using a
talkback build. And in both cases, 2001093008 works fine.

Where can I get a debug build?
Darin: 
I have a debug build but the crash on this URL that I saw is fixed with 
bug 102936 (fixed with build 20011004)

David Gerard:
>Where can I get a debug build?
You must compile your own debug build (http://www.mozilla.org/build)
Matti: So... WFM with the current build?
WFM with build 2001100403-trunk (both URLs).
Developers of Mozilla are generating and solving bugs faster, that they can 
analyse it =)
Marking WFM per reporter's comment ("WFM with build 2001100403-trunk").
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
glad to see that this was just a dupe of that other bug :)
Adding topcrash keyword and Trunk [@ nsHttpTransaction::Release] for future
reference.  This *was* a topcrasher according to Talkback data, but the last
build to show this crash was MozillaTrunk 2001100109.
Keywords: topcrash
Summary: browser crash while loading page → browser crash while loading page - Trunk [@ nsHttpTransaction::Release]
taking for 0.9.6 though the stack traces so far are pretty useless.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
SPAM -- never mind.. forgot that this was closed :/
Priority: P1 → --
Target Milestone: mozilla0.9.6 → ---
Verified WFM.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
Crash Signature: [@ nsHttpTransaction::Release]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: