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

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Octoploid]

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)

Comment 1

[Octoploid]

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

Comment 2

[Toshihiro Yamada]

2015-02-18 win64 nightly crashed with a similar stack trace.

Crash report:bp-b95e80c0-fc2a-477f-aa76-339502150218

Comment 4

[Matthias Versen [:Matti]]

bug 1134254 contains STR : Just install Noscript and visit http://google.com

Comment 5

[Johannes Pfrang [:johnp]]

Caused by bug 1099296?

Comment 6

[Johannes Pfrang [:johnp]]

Ahh, nevermind... didn't see the blocking bug is already set.

Comment 7

[bull500]

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

[Honza Bambas (:mayhemer)]

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

[Daniel Holbert [:dholbert]]

(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

[Honza Bambas (:mayhemer)]

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

[Honza Bambas (:mayhemer)]

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

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Crash regression from bug 1099296.

Comment 13

[Raul Nicolae Malea]

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

Comment 14

[Christoph Kerschbaumer [:ckerschb}]

(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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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.

Comment 16

[Honza Bambas (:mayhemer)]

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?

Comment 17

[Christoph Kerschbaumer [:ckerschb}]

(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.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(There's not that many)

Comment 20

[Christoph Kerschbaumer [:ckerschb}]

(In reply to Jonas Sicking (:sicking) from comment #19)
> (There's not that many)

On my list :-)

Comment 21

[Christoph Kerschbaumer [:ckerschb}]

Attachment: allow_null_loadinfo_in_newchannelinternal.patch

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?

Comment 22

[Christoph Kerschbaumer [:ckerschb}]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9305c6f70f01

Comment 23

[Peja Stija]

Related?

Nightly build 20150218030228 crashes Firefox instantly when trying to update a GreaseMonkey script.

Comment 24

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9305c6f70f01

Comment 25

[Johannes Pfrang [:johnp]]

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

[Johannes Pfrang [:johnp]]

Ahh, ok. I just saw this *just* missed today's Nightly. I'd still vote for a Nightly re-spin if possible.

Comment 27

[Lily Kim]

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

[Ryan VanderMeulen [:RyanVM]]

Wasn't for this bug, but there's a respin in progress anyway.

Comment 31

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Socorro shows no more crashes for any of these signatures, after this fix was applied, so I believe this is now fixed.