Closed
Bug 102864
Opened 23 years ago
Closed 23 years ago
browser crash while loading page - Trunk [@ nsHttpTransaction::Release]
Categories
(Core :: Networking: HTTP, defect)
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
Reporter | ||
Comment 1•23 years ago
|
||
Also: TB36203132E TB36203096X On old 2001083103 on Win98 it is okay.
Reporter | ||
Comment 2•23 years ago
|
||
Also on: http://zpravy.idnes.cz/domaci.asp?r=domaci&c=A010816_221308_domaci_itu&l=1&t=A010816 TB36203521M
Comment 3•23 years ago
|
||
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?
Comment 4•23 years ago
|
||
Comment 5•23 years ago
|
||
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 ;).
Reporter | ||
Comment 6•23 years ago
|
||
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]
Comment 10•23 years ago
|
||
David Baron: Though that one talkback doesn't make sense, are any of the other talkbacks useful?
Assignee | ||
Comment 11•23 years ago
|
||
dbaron: needless to say, that stack trace seems bogus... nsHttpChannel::GetStatus doesn't release anything.. certainly not a nsHttpTransaction.
Assignee | ||
Comment 12•23 years ago
|
||
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!
Comment 13•23 years ago
|
||
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)
Comment 14•23 years ago
|
||
Reporter | ||
Comment 15•23 years ago
|
||
Assignee | ||
Comment 16•23 years ago
|
||
so, both of these logs correspond to a crash?
Comment 17•23 years ago
|
||
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.
Assignee | ||
Comment 18•23 years ago
|
||
adam, matti: do either of you have a debug build? the http log file is not telling me much.
Reporter | ||
Comment 19•23 years ago
|
||
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 =)]
Reporter | ||
Comment 20•23 years ago
|
||
Reporter | ||
Comment 21•23 years ago
|
||
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?
Comment 22•23 years ago
|
||
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?
Comment 23•23 years ago
|
||
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)
Comment 24•23 years ago
|
||
Matti: So... WFM with the current build?
Reporter | ||
Comment 25•23 years ago
|
||
WFM with build 2001100403-trunk (both URLs). Developers of Mozilla are generating and solving bugs faster, that they can analyse it =)
Comment 26•23 years ago
|
||
Marking WFM per reporter's comment ("WFM with build 2001100403-trunk").
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 27•23 years ago
|
||
glad to see that this was just a dupe of that other bug :)
Comment 28•23 years ago
|
||
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]
Assignee | ||
Comment 29•23 years ago
|
||
taking for 0.9.6 though the stack traces so far are pretty useless.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
Assignee | ||
Comment 30•23 years ago
|
||
SPAM -- never mind.. forgot that this was closed :/
Priority: P1 → --
Target Milestone: mozilla0.9.6 → ---
Updated•13 years ago
|
Crash Signature: [@ nsHttpTransaction::Release]
You need to log in
before you can comment on or make changes to this bug.
Description
•