Browser Buster test not loading subsequent pages(busted)

VERIFIED WORKSFORME

Status

()

Core
Networking: HTTP
VERIFIED WORKSFORME
17 years ago
17 years ago

People

(Reporter: Claudius Gayle, Assigned: Gagan)

Tracking

({regression})

Trunk
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
I stumbled upon this while verifying bug 69843. Evidently a new problem has
crept into the build that has caused the browser Buster endurance test to stop
working again.
This appears to be a new regression with the 2001032708 builds as the 2001032308
builds work fine.
In a nutshell, clicking the link starts the test and yahoo loads but then
nothing else. This is the entire console output:

+++ loading http://www.yahoo.com
Document http://www.maubi.net/cgi-bin/buster.cgi?refresh=10 loaded successfully
Error loading URL
http://www.maubi.net/cgi-bin/buster.cgi?file=500.list&page=1&last=-1&refresh=10:
804b0002 
Error loading URL
http://www.maubi.net/cgi-bin/buster.cgi?file=500.list&page=1&last=-1&refresh=10:
80004005 

the component is just a wild guess since that's where the last related bug went.

I've verified the broken behavior on 2001032708 trunk builds on NT4 and Linux
and would suspect this is all/all.
(Reporter)

Updated

17 years ago
Keywords: regression
I stepped thro' some code I checked in last friday and I don't see any problem 
there. I did notice that after loading yahoo.com, the message, "Error 
loading....." message comes only 2 times. After that the browser does nothing. 
nsDocShell::OnStateChange() is passed a error code though. I think something in 
necko/cache or uriloader is broken. First trying necko

nsWebShell::EndPageLoad(nsIWebProgress * 0x040de9c4, nsIChannel * 0x05a1fe00, 
unsigned int 2152857618) line 1174
nsDocShell::OnStateChange(nsDocShell * const 0x040dd310, nsIWebProgress * 
0x040de9c4, nsIRequest * 0x05a1fe00, int 131088, unsigned int 2152857618) line 
2632
nsWebShell::OnStateChange(nsWebShell * const 0x040dd310, nsIWebProgress * 
0x040de9c4, nsIRequest * 0x05a1fe00, int 131088, unsigned int 2152857618) line 
951
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x040de9c4, nsIRequest * 
0x05a1fe00, int 131088, unsigned int 2152857618) line 1309
nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x05a1fe00, unsigned int 
2152857618) line 736
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 2152857618) line 632
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x040de9b4, nsIRequest * 
0x05a1fe00, nsISupports * 0x00000000, unsigned int 2152857618, const unsigned 
short * 0x100b1a48 gCommonEmptyBuffer) line 564
nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x040de940, nsIRequest * 
0x05a1fe00, nsISupports * 0x00000000, unsigned int 2152857618, const unsigned 
short * 0x100b1a48 gCommonEmptyBuffer) line 518 + 48 bytes
Assignee: radha → gagan
Component: History: Session → Networking: HTTP
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
This seems to be working now. Marking WFM.
(Reporter)

Comment 3

17 years ago
you're right. this seems to work with a 2001032908 linux build now. Mystery fix?
Marking VERIFIED Worksforme
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.