Closed Bug 23967 Opened 25 years ago Closed 25 years ago

[DOGFOOD] browser crashes running "-f bloaturls.txt"

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: waterson, Assigned: gagan)

Details

(Keywords: crash)

Attachments

(1 file)

I found this uninitialized variable. Might fix it.
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
This may have been due to the warren/andreas checkin last night.
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.
I suggest changing res:///res/samples/test2.html to
resource:///res/samples/test2.html

res and resource have been switched.
bloaty test still crashes with uninit var. patch applied.  (Linux)
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?
I've seen only resource-urls so far.
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.
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.
andreas/warren, can you confirm that this is the right thing to do, and I'll
check it in.
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this should be fixed, I just backed out andreas.
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).
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.
warren/andreas, if res: needs to go away, we should
file a separate bug for that.
Adding crash keyword
Keywords: crash
verified:
Linux 2000070420
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: