Josh Matthews [:jdm] Reporter
	Description • 14 years ago

This is a low-volume Fennec crash (4 in three weeks, I think), but it exists and it is perplexing.

http://crash-stats.mozilla.com/report/index/cf865776-f102-499f-9252-385522101011
http://crash-stats.mozilla.com/report/index/2398a47c-756a-4910-a6ca-f04372101020

254  mRedirectCallback->OnRedirectVerifyCallback(result);

mRedirectCallback is obviously corrupt here.

	Josh Matthews [:jdm] Reporter
	Comment 1 • 14 years ago

Hmm, so the ones from a couple days ago have this stack:

0 	libxul.so 	mozilla::net::HttpChannelParentListener::OnContentRedirectResultReceived 	nsCOMPtr.h:800
1 	libxul.so 	mozilla::net::HttpChannelParent::RecvRedirect2Verify 	netwerk/protocol/http/HttpChannelParent.cpp:297
2 	libxul.so 	mozilla::net::PHttpChannelParent::OnMessageReceived 	PHttpChannelParent.cpp:599
3 	libxul.so 	mozilla::dom::PContentParent::OnMessageReceived 	PContentParent.cpp:463
4 	libxul.so 	mozilla::ipc::AsyncChannel::OnDispatchMessage 	ipc/glue/AsyncChannel.cpp:262
5 	libxul.so 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:440
6 	libxul.so 	RunnableMethod<mozilla::ipc::RPCChannel, bool , Tuple0>::Run 	ipc/chromium/src/base/task.h:308
7 	libxul.so 	mozilla::ipc::RPCChannel::DequeueTask::Run 	RPCChannel.h:474
8 	libxul.so 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:344
9 	libxul.so 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/message_loop.cc:354
10 	libxul.so 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:451
11 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:115
12 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:220
13 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:512
14 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:186
15 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:192
16 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3684
17 	libxul.so 	GeckoStart 	toolkit/xre/nsAndroidStartup.cpp:131
18 	libc.so 	libc.so@0x10f47 	
19 	libc.so 	libc.so@0x10a33 	

But the new one from today shows a different top line, leading me to think that I was wrong about mRedirectCallback being the culprit:

0 	libxul.so 	mozilla::net::HttpChannelParentListener::OnContentRedirectResultReceived 	netwerk/protocol/http/HttpChannelParentListener.cpp:254
1 	libxul.so 	mozilla::net::HttpChannelParent::RecvRedirect2Verify 	netwerk/protocol/http/HttpChannelParent.cpp:297

This lines up with:

252 newHttpChannel->SetRequestHeader(changedHeaders[i].mHeader,
253                                  changedHeaders[i].mValue,
254                                  changedHeaders[i].mMerge); 

so I guess that when we get newHttpChannel via

247 nsHttpChannel* newHttpChannel =
248   static_cast<nsHttpChannel*>(mRedirectChannel->mChannel.get());

then mRedirectChannel is bogus instead.

	Brad Lassey [:blassey] (use needinfo?)
	Comment 2 • 14 years ago

(In reply to comment #0)
> This is a low-volume Fennec crash (4 in three weeks, I think), but it exists
> and it is perplexing.

looks like the frequency of this has picked up a bit, 6 in the last 3 days, which makes it th #10 top crash for fennec.

	Honza Bambas (:mayhemer)
	Comment 3 • 14 years ago

This could be dupe of bug 591707.

	Honza Bambas (:mayhemer)
	Comment 4 • 14 years ago

Happens during redirect to e.g. an ftp protocol:

nsHttpChannel* newHttpChannel = 
      static_cast<nsHttpChannel*>(mRedirectChannel->mChannel.get());

where mRedirectChannel->mChannel.get() is nsFtpChannel is obviously wrong.

Stack trace:

 	xul.dll!SearchTable(PLDHashTable * table=0x06dd3fb4, const void * key=0x067afb80, unsigned int keyHash=0x3c6ef372, PLDHashOperator op=PL_DHASH_LOOKUP)  Line 432 + 0x3 bytes	C
 	xul.dll!PL_DHashTableOperate(PLDHashTable * table=0x06dd3fb4, const void * key=0x067afb80, PLDHashOperator op=PL_DHASH_LOOKUP)  Line 625 + 0x13 bytes	C
 	xul.dll!nsTHashtable<nsBaseHashtableET<nsStringHashKey,nsCOMPtr<nsIVariant> > >::GetEntry(const nsAString_internal & aKey={...})  Line 170 + 0x18 bytes	C++
 	xul.dll!nsInterfaceHashtable<nsStringHashKey,nsIVariant>::Get(const nsAString_internal & aKey={...}, nsIVariant * * pInterface=0x067afb8c)  Line 122 + 0xc bytes	C++
 	xul.dll!nsHashPropertyBag::GetProperty(const nsAString_internal & name={...}, nsIVariant * * _retval=0x067afb8c)  Line 110 + 0x13 bytes	C++
>	xul.dll!mozilla::net::HttpChannelParentListener::OnContentRedirectResultReceived(const unsigned int result=0x00000000, const nsTArray<mozilla::net::RequestHeaderTuple> & changedHeaders={...})  Line 261	C++
 	xul.dll!mozilla::net::HttpChannelParent::RecvRedirect2Verify(const unsigned int & result=0x00000000, const nsTArray<mozilla::net::RequestHeaderTuple> & changedHeaders={...})  Line 296	C++
 	xul.dll!mozilla::net::PHttpChannelParent::OnMessageReceived(const IPC::Message & __msg={...})  Line 595 + 0x21 bytes	C++

	Jason Duell
	Comment 5 • 14 years ago

This could also be bug 590682.  We're doing a redirect to something other than a nsHttpChannel, but we're static_cast-ing it to nsHttpChannel.   Could be FTP, or a custom protocol that wraps HTTP.   Would be nice to know which is more common.