Closed
Bug 23967
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] browser crashes running "-f bloaturls.txt"
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: waterson, Assigned: gagan)
Details
(Keywords: crash)
Attachments
(1 file)
834 bytes,
patch
|
Details | Diff | Splinter Review |
To reproduce: run "mozilla -f bloaturls.txt". I get the below stack trace, where i_Query points to garbage. Marking as DOGFOOD/blocker because this kills bloaty. #0 0x4061bbb5 in nsStdURL::SetQuery (this=0x82c2218, i_Query=0x723d656d <Address 0x723d656d out of bounds>) at nsStdURL.cpp:502 #1 0x416144ca in nsResourceProtocolHandler::NewChannel (this=0x8505ec0, verb=0x40c9e530 "", uri=0x83b7408, aLoadGroup=0x8513608, notificationCallbacks=0x8512fcc, loadAttributes=0, originalURI=0x0, bufferSegmentSize=0, bufferMaxSize=0, result=0xbfffe664) at nsResourceProtocolHandler.cpp:332 #2 0x4060f8aa in nsIOService::NewChannelFromURI (this=0x80ad4f8, verb=0x40c9e530 "", aURI=0x83b7408, aGroup=0x8513608, notificationCallbacks=0x8512fcc, loadAttributes=0, originalURI=0x0, bufferSegmentSize=0, bufferMaxSize=0, result=0xbfffe664) at nsIOService.cpp:259 #3 0x40c9a377 in nsDocumentOpenInfo::Open (this=0x82b7cd8, aURI=0x83b7408, aCommand=0, aWindowTarget=0x0, aWindowContext=0x8513060, aReferringURI=0x0, aPostData=0x0, aOpenContext=0x8513608, aCurrentOpenContext=0xbfffe7bc) at nsURILoader.cpp:187 #4 0x40c9b52e in nsURILoader::OpenURIWithPostDataVia (this=0x8167440, aURI=0x83b7408, aCommand=0, aWindowTarget=0x0, aWindowContext=0x8513060, aReferringURI=0x0, aPostDataStream=0x0, aOpenContext=0x8513608, aCurrentOpenContext=0xbfffe7bc, adapterBinding=0) at nsURILoader.cpp:500 #5 0x40c9b415 in nsURILoader::OpenURIVia (this=0x8167440, aURI=0x83b7408, aCommand=0, aWindowTarget=0x0, aWindowContext=0x8513060, aReferringURI=0x0, aOpenContext=0x8513608, aCurrentOpenContext=0xbfffe7bc, aLocalIP=0) at nsURILoader.cpp:457 #6 0x40c9b3bd in nsURILoader::OpenURI (this=0x8167440, aURI=0x83b7408, aCommand=0, aWindowTarget=0x0, aWindowContext=0x8513060, aReferringURI=0x0, aOpenContext=0x8513608, aCurrentOpenContext=0xbfffe7bc) at nsURILoader.cpp:443 #7 0x40b856f5 in nsDocLoaderImpl::LoadDocument (this=0x85135b0, aUri=0x83b7408, aCommand=0x40ba31f4 "view", aContainer=0x8513060, aPostDataStream=0x0, aExtraInfo=0x0, aType=0, aLocalIP=0, aReferrer=0x0) at nsDocLoader.cpp:384 #8 0x40b8ba6c in nsWebShell::DoLoadURL (this=0x8512fb0, aUri=0x83b7408, aCommand=0x40ba31f4 "view", aPostDataStream=0x0, aType=0, aLocalIP=0, aReferrer=0x0, aKickOffLoad=1) at nsWebShell.cpp:1676 #9 0x40b8c6bd in nsWebShell::LoadURI (this=0x8512fb0, aUri=0x83b7408, aCommand=0x40ba31f4 "view", aPostDataStream=0x0, aModifyHistory=1, aType=0, aLocalIP=0, aHistoryState=0x0, aReferrer=0x0) at nsWebShell.cpp:1929 #10 0x40b8d69c in nsWebShell::LoadURL (this=0x8512fb0, aURLSpec=0xbfffefb8, aCommand=0x40ba31f4 "view", aPostDataStream=0x0, aModifyHistory=1, aType=0, aLocalIP=0, aHistoryState=0x0, aReferrer=0x0) at nsWebShell.cpp:2160 #11 0x40b8ab0b in nsWebShell::LoadURL (this=0x8512fb0, aURLSpec=0xbfffefb8, aPostDataStream=0x0, aModifyHistory=1, aType=0, aLocalIP=0, aHistoryState=0x0, aReferrer=0x0) at nsWebShell.cpp:1483 #12 0x41569949 in nsBrowserInstance::LoadUrl (this=0x8559028, aUrl=0xbfffefb8) at nsBrowserInstance.cpp:962 #13 0x4156d995 in PageCycler::Observe (this=0x855af88, aSubject=0x8504000, aTopic=0xbffff1e0, someData=0xbffff278) at nsBrowserInstance.cpp:1064 #14 0x40139c73 in nsObserverService::Notify (this=0x808f1f0, aSubject=0x8504000, aTopic=0xbffff1e0, someData=0xbffff278) at nsObserverService.cpp:239 #15 0x4156baf7 in nsBrowserInstance::OnEndDocumentLoad (this=0x8559028, aLoader=0x85135b0, channel=0x813a320, aStatus=0) at nsBrowserInstance.cpp:1532 #16 0x40b9059a in nsWebShell::OnEndDocumentLoad (this=0x8512fb0, loader=0x85135b0, channel=0x813a320, aStatus=0) at nsWebShell.cpp:3116 #17 0x40b86586 in nsDocLoaderImpl::FireOnEndDocumentLoad (this=0x85135b0, aLoadInitiator=0x85135b0, aDocChannel=0x813a320, aStatus=0) at nsDocLoader.cpp:812 #18 0x40b86223 in nsDocLoaderImpl::DocLoaderIsEmpty (this=0x85135b0, aStatus=0) at nsDocLoader.cpp:702 #19 0x40b86098 in nsDocLoaderImpl::OnStopRequest (this=0x85135b0, aChannel=0x8547be0, aCtxt=0x0, aStatus=0, aMsg=0x0) at nsDocLoader.cpp:647 #20 0x40620cc2 in nsLoadGroup::RemoveChannel (this=0x8513608, channel=0x8547be0, ctxt=0x0, status=0, errorMsg=0x0) at nsLoadGroup.cpp:532 #21 0x41594ff3 in nsHTTPChannel::ResponseCompleted (this=0x8547be0, aTransport=0x853611c, aListener=0x849d788, aStatus=0, aMsg=0x0) at nsHTTPChannel.cpp:1320 #22 0x41599588 in nsHTTPResponseListener::OnStopRequest (this=0x8499ea0, channel=0x853611c, i_pContext=0x8547be0, i_Status=0, i_pMsg=0x0) at nsHTTPResponseListener.cpp:253 #23 0x4060df8d in nsOnStopRequestEvent::HandleEvent (this=0x85175d0) at nsAsyncStreamListener.cpp:278 #24 0x4060d677 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x84efb68) at nsAsyncStreamListener.cpp:93 #25 0x401da36b in PL_HandleEvent (self=0x84efb68) at plevent.c:522 #26 0x401da27c in PL_ProcessPendingEvents (self=0x80ab8d0) at plevent.c:483 #27 0x401710dc in nsEventQueueImpl::ProcessPendingEvents (this=0x80ab8a8) at nsEventQueue.cpp:228 #28 0x406cfe54 in event_processor_callback (data=0x80ab8a8, source=7, condition=GDK_INPUT_READ) at nsAppShell.cpp:141 #29 0x406cfadf in our_gdk_io_invoke (source=0x8145d70, condition=G_IO_IN, data=0x81c3610) at nsAppShell.cpp:54 #30 0x4088652a in ?? () from /usr/lib/libglib-1.2.so.0 #31 0x40887be6 in ?? () from /usr/lib/libglib-1.2.so.0 #32 0x408881a1 in ?? () from /usr/lib/libglib-1.2.so.0 #33 0x40888341 in ?? () from /usr/lib/libglib-1.2.so.0 #34 0x407b2209 in ?? () from /usr/lib/libgtk-1.2.so.0 #35 0x406d0457 in nsAppShell::Run (this=0x8096508) at nsAppShell.cpp:304 #36 0x4058727d in ?? () from /home/waterson/seamonkey/mozilla/dist/bin/./libnsappshell.so #37 0x804bf3d in main1 (argc=3, argv=0xbffffc24) at nsAppRunner.cpp:622 #38 0x804c3c7 in main (argc=3, argv=0xbffffc24) at nsAppRunner.cpp:710
Comment 1•25 years ago
|
||
This may have been due to the warren/andreas checkin last night.
Reporter | ||
Comment 2•25 years ago
|
||
The URL it's trying to open (at frame #11) is "res:///res/samples/test2.html" so it could very well be that "res:" URL parsing whacked this somehow.
Comment 3•25 years ago
|
||
I suggest changing res:///res/samples/test2.html to resource:///res/samples/test2.html res and resource have been switched.
Comment 4•25 years ago
|
||
Comment 5•25 years ago
|
||
bloaty test still crashes with uninit var. patch applied. (Linux)
Comment 6•25 years ago
|
||
changing res: to resource: fixes the bloaty test for me. Don't we use res: in other places? Do those need to change as well?
Comment 7•25 years ago
|
||
I've seen only resource-urls so far.
Comment 8•25 years ago
|
||
We're currently building (at least on windows) both protocol handlers (one for res and one for resource) so the one that isn't compat w/ the new url parsing code is still being used and thus is building bad urls.
Comment 9•25 years ago
|
||
It's sounding like some old "resource:" usages weren't caught and changed. To remove confusion I'm going to pull the netwerk/protocol/resource protocol dir out of the builds.
Comment 10•25 years ago
|
||
andreas/warren, can you confirm that this is the right thing to do, and I'll check it in.
Comment 11•25 years ago
|
||
Hmmm ... I just looked into my local netwerk/protocol/Makefile.in and I noticed that I had already removed resource from the build. This is the reason I was able to catch the res:/// usage in bloaturls.txt. I would say, go for it.
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 12•25 years ago
|
||
this should be fixed, I just backed out andreas.
Comment 13•25 years ago
|
||
res: was never a protocol we used. It was an interim thing I used to get the new resource implementation running. Note that resource: is implemented by netwerk/protocol/res (not netwerk/protocol/resource which is the old one).
Comment 14•25 years ago
|
||
Then I suggest changing res: to resource: in bloaturls.txt and remove the resource protocol from the build. As a sidenote: the method GetScheme of the ResProtocolHandler still gives "res" back not "resource". Should be changed too.
Comment 15•25 years ago
|
||
warren/andreas, if res: needs to go away, we should file a separate bug for that.
You need to log in
before you can comment on or make changes to this bug.
Description
•