Closed Bug 1134196 Opened 7 years ago Closed 7 years ago

crash in mozilla::net::nsHttpChannel::ContinueProcessRedirectionAfterFallback(nsresult) () with NoScript

Categories

(Core :: Networking: HTTP, defect)

x86_64
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla38
Tracking Status
firefox38 --- verified

People

(Reporter: octoploid, Assigned: ckerschb)

References

Details

(Keywords: crash, dogfood, regression)

Crash Data

Attachments

(1 file)

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
Blocks: 1099296
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
2015-02-18 win64 nightly crashed with a similar stack trace.

Crash report:bp-b95e80c0-fc2a-477f-aa76-339502150218
Duplicate of this bug: 1134254
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
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.
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.
Blocks: 965413
(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.)
Keywords: crash, dogfood
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.
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.
[Tracking Requested - why for this release]: Crash regression from bug 1099296.
No longer blocks: 965413
Flags: needinfo?(mozilla)
(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)
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
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?
(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: 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.
(In reply to Jonas Sicking (:sicking) from comment #19)
> (There's not that many)

On my list :-)
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?(jduell.mcbugs)
Attachment #8566273 - Flags: review?(jduell.mcbugs) → review+
Related?

Nightly build 20150218030228 crashes Firefox instantly when trying to update a GreaseMonkey script.
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) ]
https://hg.mozilla.org/mozilla-central/rev/9305c6f70f01
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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.
Ahh, ok. I just saw this *just* missed today's Nightly. I'd still vote for a Nightly re-spin if possible.
Would agree that it would be very useful to have a re-spin to apply this fix to the nightly today, if possible.
Wasn't for this bug, but there's a respin in progress anyway.
Duplicate of this bug: 1134583
Duplicate of this bug: 1134575
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() ]
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.