Closed
Bug 1134196
Opened 9 years ago
Closed 9 years ago
crash in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () with NoScript
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
VERIFIED
FIXED
mozilla38
Tracking | Status | |
---|---|---|
firefox38 | --- | verified |
People
(Reporter: octoploid, Assigned: ckerschb)
References
Details
(Keywords: crash, dogfood, regression)
Crash Data
Attachments
(1 file)
2.26 KB,
patch
|
sicking
:
review+
jduell.mcbugs
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2305.0 Safari/537.36 Steps to reproduce: Go to faz.net Actual results: Firefox crashes: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4700515 in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () from /var/tmp/moz-build-dir/dist/bin/libxul.so (gdb) bt #0 0x00007ffff4700515 in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #1 0x00007ffff46f6ee1 in mozilla::net::nsHttpChannel::AsyncProcessRedirection(unsigned int) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #2 0x00007ffff46f9996 in mozilla::net::nsHttpChannel::ProcessResponse() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #3 0x00007ffff4703cc8 in mozilla::net::nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #4 0x00007ffff45e8dc3 in nsInputStreamPump::OnStateStart() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #5 0x00007ffff45e8b00 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #6 0x00007ffff45662c0 in nsOutputStreamReadyEvent::Run() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #7 0x00007ffff4577c31 in nsThread::ProcessNextEvent(bool, bool*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #8 0x00007ffff4591e63 in NS_ProcessNextEvent(nsIThread*, bool) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #9 0x00007ffff4765a1e in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #10 0x00007ffff4751698 in MessageLoop::Run() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #11 0x00007ffff592ba8b in nsBaseAppShell::Run() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #12 0x00007ffff5ecd4ce in nsAppStartup::Run() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #13 0x00007ffff5ef844d in XREMain::XRE_mainRun() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #14 0x00007ffff5ef86c4 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #15 0x00007ffff5ef8abf in XRE_main () from /var/tmp/moz-build-dir/dist/bin/libxul.so #16 0x00000000004035a1 in main () Expected results: (Sorry no debug symbols)
With debug symbols I get: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff34c4728 in NS_NewChannelInternal (outChannel=<optimized out>, aUri=0x5048ae0, aLoadInfo=<optimized out>, aLoadGroup=0x0, aCallbacks=<optimized out>, aLoadFlags=<optimized out>, aIoService=0x53b5e0) at /var/tmp/mozilla-central/netwerk/base/nsNetUtil.h:327 327 MOZ_ASSERT(aLoadInfo, "Can not create a channel without a loadInfo"); (gdb) bt #0 0x00007ffff34c4728 in NS_NewChannelInternal (outChannel=<optimized out>, aUri=0x5048ae0, aLoadInfo=<optimized out>, aLoadGroup=0x0, aCallbacks=<optimized out>, aLoadFlags=<optimized out>, aIoService=0x53b5e0) at /var/tmp/mozilla-central/netwerk/base/nsNetUtil.h:327 #1 0x00007ffff351a19f in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback (this=this@entry=0x4ff5850, rv=nsresult::NS_OK) at /var/tmp/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:4445 #2 0x00007ffff351a6d8 in ContinueProcessRedirectionAfterFallback (rv=nsresult::NS_OK, this=0x4ff5850) at /var/tmp/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:4388 #3 mozilla::net::nsHttpChannel::AsyncProcessRedirection (this=this@entry=0x4ff5850, redirectType=<optimized out>) at /var/tmp/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:4392 #4 0x00007ffff351b20f in mozilla::net::nsHttpChannel::HandleAsyncRedirect (this=0x4ff5850) at /var/tmp/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:493 #5 0x00007ffff31cd01f in nsRunnableMethodImpl<nsresult (nsMemoryReporterManager::*)(), void, true>::Run (this=<optimized out>) at ../../dist/include/nsThreadUtils.h:386 #6 0x00007ffff3255310 in nsThread::ProcessNextEvent (this=0x4b7050, aMayWait=<optimized out>, aResult=0x7fffffffcb2f) at /var/tmp/mozilla-central/xpcom/threads/nsThread.cpp:855 #7 0x00007ffff3284fbd in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /var/tmp/mozilla-central/xpcom/glue/nsThreadUtils.cpp:265 #8 0x00007ffff35b67eb in mozilla::ipc::MessagePump::Run (this=0x4b5900, aDelegate=0x4b67e0) at /var/tmp/mozilla-central/ipc/glue/MessagePump.cpp:99 #9 0x00007ffff359017c in MessageLoop::RunInternal (this=0x4b67e0) at /var/tmp/mozilla-central/ipc/chromium/src/base/message_loop.cc:233 #10 0x00007ffff3590217 in RunHandler (this=<optimized out>) at /var/tmp/mozilla-central/ipc/chromium/src/base/message_loop.cc:226 #11 MessageLoop::Run (this=<optimized out>) at /var/tmp/mozilla-central/ipc/chromium/src/base/message_loop.cc:200 #12 0x00007ffff4e1a4a9 in nsBaseAppShell::Run (this=0x8dc380) at /var/tmp/mozilla-central/widget/nsBaseAppShell.cpp:164 #13 0x00007ffff56ca332 in nsAppStartup::Run (this=0x89aea0) at /var/tmp/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:281 #14 0x00007ffff5725d21 in XREMain::XRE_mainRun (this=this@entry=0x7fffffffcef0) at /var/tmp/mozilla-central/toolkit/xre/nsAppRunner.cpp:4160 #15 0x00007ffff5727091 in XREMain::XRE_main (this=this@entry=0x7fffffffcef0, argc=argc@entry=1, argv=argv@entry=0x7fffffffe3a8, aAppData=aAppData@entry=0x7fffffffd120) at /var/tmp/mozilla-central/toolkit/xre/nsAppRunner.cpp:4236 #16 0x00007ffff5727419 in XRE_main (argc=1, argv=0x7fffffffe3a8, aAppData=0x7fffffffd120, aFlags=<optimized out>) at /var/tmp/mozilla-central/toolkit/xre/nsAppRunner.cpp:4456 #17 0x00000000004041ad in do_main (argc=argc@entry=1, argv=argv@entry=0x7fffffffe3a8, xreDirectory=0x42dc20) at /var/tmp/mozilla-central/browser/app/nsBrowserApp.cpp:294 #18 0x00000000004032b0 in main (argc=1, argv=0x7fffffffe3a8) at /var/tmp/mozilla-central/browser/app/nsBrowserApp.cpp:667
Updated•9 years ago
|
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Comment 2•9 years ago
|
||
2015-02-18 win64 nightly crashed with a similar stack trace. Crash report:bp-b95e80c0-fc2a-477f-aa76-339502150218
Comment 4•9 years ago
|
||
bug 1134254 contains STR : Just install Noscript and visit http://google.com
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ NS_NewChannelInternal(nsIChannel**, nsIURI*, nsILoadInfo*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) ]
Ever confirmed: true
Keywords: regression
OS: Linux → All
Summary: crash in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () → crash in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () with NoScipt
Comment 5•9 years ago
|
||
Caused by bug 1099296?
Comment 6•9 years ago
|
||
Ahh, nevermind... didn't see the blocking bug is already set.
Summary: crash in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () with NoScipt → crash in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () with NoScript
This crash happens every time i visit this link(http://pops.ci/x35aZO) on Linux Fedora 21 Nightly 38.0a1 (2015-02-18) Crash Report - https://crash-stats.mozilla.com/report/index/566aa50e-8c01-40f0-b3ce-549e12150218 And i dont know if this is related to the NoScript add-on as in the Summary here, but for me it occurs without it installed.
Comment 8•9 years ago
|
||
Can reproduce with FireGestures and using Hybrid Save gesture on any bugzilla attachment. I'm in possession of nsHttp:4 log right now. Will report shortly.
Comment 9•9 years ago
|
||
(This gave me insta-startup-crashes on 2 different machines [when restoring an existing browsing session] until I was able to get into safe mode & remove noscript. --> adding "dogfood" keyword; nobody likes startup crashes.)
Comment 10•9 years ago
|
||
Apparently any http channel that redirects and has not been set load info crashes.
In case of the FireGestures extension I can see the following in the console (current m-c):
JavaScript strict warning: chrome://browser/content/nsContextMenu.js, line 1249: ReferenceError: reference to undefined property this.principal
JavaScript strict warning: chrome://browser/content/nsContextMenu.js, line 1514: ReferenceError: reference to undefined property this.target
The first is the interesting one:
var channel = ioService.newChannelFromURI2(makeURI(linkURL),
null, // aLoadingNode
> this.principal, // aLoadingPrincipal
null, // aTriggeringPrincipal
Ci.nsILoadInfo.SEC_NORMAL,
Ci.nsIContentPolicy.TYPE_OTHER);
...in saveHelper function. Since both aLoadingNode and aLoadingPrincipal are null, there is no load info.
Comment 11•9 years ago
|
||
This is probably a workaround only, or a completely undesired solution, but nsHttpChannel::ContinueProcessRedirectionAfterFallback should use the more customizable version of NS_NewChannelInternal and fill some of the properties extracted (under normal circumstances) from load info as nulls.
Comment 12•9 years ago
|
||
[Tracking Requested - why for this release]: Crash regression from bug 1099296.
Comment 13•9 years ago
|
||
My crash: https://crash-stats.mozilla.com/report/index/f6aaa332-c912-4a95-befa-0fe792150218 https://crash-stats.mozilla.com/report/index/8a612b94-2082-4c19-8179-67c642150218 https://crash-stats.mozilla.com/report/index/38b2f289-acd4-4725-b5e7-5904b2150218 https://crash-stats.mozilla.com/report/index/2cd81404-8378-4209-8134-773802150218
Blocks: 965413
tracking-firefox38:
? → ---
Assignee | ||
Comment 14•9 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #12) > [Tracking Requested - why for this release]: Crash regression from bug > 1099296. We have a meeting in 5 minutes, and I will bring it up. Potentially we can remove the assertion, addons shouldn't crash. Also, this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1120487 will help resolve the problem - but that's a little further down the road.
Flags: needinfo?(mozilla)
Comment 15•9 years ago
|
||
The problem is not the assertion, since that's debug-only. The problem is that after the assertion NS_NewChannelInternal dereferences the null aLoadInfo pointer, That's when you crash.
No longer blocks: 965413
tracking-firefox38:
--- → ?
Comment 16•9 years ago
|
||
OK, and are we going to wait for bug 1120487 or back bug 1099296 out or do what I've suggested in comment 11 as short-term solution?
Assignee | ||
Comment 17•9 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #15) > The problem is not the assertion, since that's debug-only. The problem is > that after the assertion NS_NewChannelInternal dereferences the null > aLoadInfo pointer, That's when you crash. That is correct, with removing the assertion I meant we should make NS_NewChannelInternal to be able to handle null loadInfos. We have dedected similar issues and just decided in our meeting this is the right path forward. I will provide a patch later today that will fix the problem.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Christoph, it might be worth going through all existing NS_NewChannelInternal(loadinfo) callsites and see which ones can be simplified if we change NS_NewChannelInternal(loadinfo) to deal well with getting a null loadinfo.
(There's not that many)
Assignee | ||
Comment 20•9 years ago
|
||
(In reply to Jonas Sicking (:sicking) from comment #19) > (There's not that many) On my list :-)
Assignee | ||
Comment 21•9 years ago
|
||
I tested and reproduced the issue by following the instructions from the Description in the duplicate bug 1134254: > 1. Create a new Profile > 2. Install NoScript (https://addons.mozilla.org/de/firefox/addon/noscript/) > 3. Open google.com Before applying the attached patch, I experienced the crash as pointed out in this bug. After applying the patch it works as it should. Jonas, if we do not get a loadInfo within NS_NewChannelInternal(loadInfo), we pass 'null' for loadingNode as well as loadingPrincipal all the way to the ioservice, where we finally branch on those two arguments, see: http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIOService.cpp#774 Any objections to land this?
Attachment #8566273 -
Flags: review?(jonas)
Attachment #8566273 -
Flags: review?(jonas) → review+
Assignee | ||
Updated•9 years ago
|
Attachment #8566273 -
Flags: review?(jduell.mcbugs)
Updated•9 years ago
|
Attachment #8566273 -
Flags: review?(jduell.mcbugs) → review+
Assignee | ||
Comment 22•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/9305c6f70f01
Target Milestone: --- → mozilla38
Comment 23•9 years ago
|
||
Related? Nightly build 20150218030228 crashes Firefox instantly when trying to update a GreaseMonkey script.
Updated•9 years ago
|
Crash Signature: [@ NS_NewChannelInternal(nsIChannel**, nsIURI*, nsILoadInfo*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) ] → [@ NS_NewChannelInternal(nsIChannel**, nsIURI*, nsILoadInfo*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) ]
[@ mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) ]
Comment 25•9 years ago
|
||
Today's nightly is broken too and crashes just ONE frame later -.- bp-8d17ae42-5ad4-40bb-82c9-03b782150219 Please reopen and think about re-triggering a Nightly build once this is correctly fixed.
Comment 26•9 years ago
|
||
Ahh, ok. I just saw this *just* missed today's Nightly. I'd still vote for a Nightly re-spin if possible.
Comment 27•9 years ago
|
||
Would agree that it would be very useful to have a re-spin to apply this fix to the nightly today, if possible.
Comment 28•9 years ago
|
||
Wasn't for this bug, but there's a respin in progress anyway.
Crash Signature: [@ NS_NewChannelInternal(nsIChannel**, nsIURI*, nsILoadInfo*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) ]
[@ mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) ] → [@ NS_NewChannelInternal(nsIChannel**, nsIURI*, nsILoadInfo*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) ]
[@ mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) ]
[@ mozilla::net::nsHttpChannel::Start…
Crash Signature: , nsIIOService*) ]
[@ mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) ]
[@ mozilla::net::nsHttpChannel::StartRedirectChannelToURI(nsIURI*, unsigned int) ] → , nsIIOService*) ]
[@ mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) ]
[@ mozilla::net::nsHttpChannel::StartRedirectChannelToURI(nsIURI*, unsigned int) ]
[@ nsILoadInfo::GetContentPolicyType() ]
Updated•9 years ago
|
tracking-firefox38:
? → ---
Comment 31•9 years ago
|
||
Socorro shows no more crashes for any of these signatures, after this fix was applied, so I believe this is now fixed.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•