Closed Bug 73633 Opened 24 years ago Closed 24 years ago

Browser Buster test not loading subsequent pages(busted)

Categories

(Core :: Networking: HTTP, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: cmaximus, Assigned: gagan)

References

()

Details

(Keywords: regression)

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.
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
Closed: 24 years ago
Resolution: --- → WORKSFORME
This seems to be working now. Marking WFM.
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.