830269 - crash in js::ion::IonBuilder::makeCallHelper

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

It started spiking in 21.0a1/20130113 and is #4 top crasher in this build The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1761f4a9081c&tochange=23eb44a5636b

Signature 	js::analyze::ScriptAnalysis::poppedTypes(unsigned char const*, unsigned int) More Reports Search
UUID	1692ba77-c289-4342-8c3b-78b7d2130114
Date Processed	2013-01-14 07:42:58
Uptime	502
Last Crash	13.1 hours before submission
Install Age	13.4 hours since version was first installed.
Install Time	2013-01-13 18:14:19
Product	Firefox
Version	21.0a1
Build ID	20130113031019
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64
Build Architecture	amd64
Build Architecture Info	family 15 model 107 stepping 1
Crash Reason	SIGSEGV
Crash Address	0x7f4cf5c010f0
App Notes 	
OpenGL: VMware, Inc. -- Gallium 0.4 on llvmpipe (LLVM 0x300) -- 2.1 Mesa 8.0.4 -- texture_from_pixmap
Processor Notes 	/data/socorro/stackwalk/bin/exploitable: ERROR: unable to analyze dump
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libxul.so 	js::analyze::ScriptAnalysis::poppedTypes 	js/src/jsanalyze.h:975
1 	libxul.so 	js::ion::IonBuilder::makeCallHelper 	js/src/ion/IonBuilder.cpp:4090
2 	libxul.so 	js::ion::IonBuilder::makeCallBarrier 	js/src/ion/IonBuilder.cpp:4202
3 	libxul.so 	js::ion::IonBuilder::makeCall 	js/src/ion/IonBuilder.cpp:4238
4 	libxul.so 	js::ion::IonBuilder::jsop_funapplyarguments 	js/src/ion/IonBuilder.cpp:3870
5 	libxul.so 	js::ion::IonBuilder::jsop_funapply 	js/src/ion/IonBuilder.cpp:3791
6 	libxul.so 	js::ion::IonBuilder::inspectOpcode 	js/src/ion/IonBuilder.cpp:940
7 	libxul.so 	js::ion::IonBuilder::traverseBytecode 	js/src/ion/IonBuilder.cpp:690
8 	libxul.so 	js::ion::IonBuilder::buildInline 	js/src/ion/IonBuilder.cpp:489
9 	libxul.so 	js::ion::IonBuilder::jsop_call_inline 	js/src/ion/IonBuilder.cpp:2915
10 	libxul.so 	js::ion::IonBuilder::inlineScriptedCall 	js/src/ion/IonBuilder.cpp:3331
11 	libxul.so 	js::ion::IonBuilder::jsop_call 	js/src/ion/IonBuilder.cpp:3918
12 	libxul.so 	js::ion::IonBuilder::inspectOpcode 	js/src/ion/IonBuilder.cpp:944
13 	libxul.so 	js::ion::IonBuilder::traverseBytecode 	js/src/ion/IonBuilder.cpp:690
14 	libxul.so 	js::ion::IonBuilder::build 	js/src/ion/IonBuilder.cpp:343
15 	libxul.so 	js::ion::SequentialCompileContext::compile 	js/src/ion/Ion.cpp:1220
16 	libxul.so 	js::ion::IonCompile<js::ion::SequentialCompileContext> 	js/src/ion/Ion.cpp:1181
17 	libxul.so 	js::ion::TestIonCompile 	js/src/ion/Ion.cpp:1261
18 	libxul.so 	js::mjit::stubs::TriggerIonCompile 	js/src/methodjit/StubCalls.cpp:839
19 		@0x7f4b1c8a600c 	
20 	libxul.so 	js::mjit::EnterMethodJIT 	js/src/methodjit/MethodJIT.cpp:1041
21 	libxul.so 	js::LooselyEqual 	js/src/jsinterp.cpp:665
22 	libxul.so 	js::mjit::JaegerShotAtSafePoint 	js/src/methodjit/MethodJIT.cpp:1099
23 	libxul.so 	js::mjit::JITScript::chunk 	js/src/methodjit/MethodJIT.h:859
24 	libxul.so 	js::Interpret 	js/src/jsinterp.cpp:1405
25 	libxul.so 	nsXPConnect::GetXPConnect 	nsThreadUtils.h:121
26 	libxul.so 	JSObject::growSlots 	Utility.h:148 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3ATypeInferenceOracle%3A%3AgetCallTarget%28JSScript*%2C+unsigned+int%2C+unsigned+char*%29
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aanalyze%3A%3AScriptAnalysis%3A%3ApoppedTypes%28unsigned+char+const*%2C+unsigned+int%29

Comment 1

[Nicolas B. Pierron [:nbp]]

(In reply to Scoobidiver from comment #0)
> Frame 	Module 	Signature 	Source
> 0 	libxul.so 	js::analyze::ScriptAnalysis::poppedTypes 
> js/src/jsanalyze.h:975
> 1 	libxul.so 	js::ion::IonBuilder::makeCallHelper 
> js/src/ion/IonBuilder.cpp:4090
> 2 	libxul.so 	js::ion::IonBuilder::makeCallBarrier 
> js/src/ion/IonBuilder.cpp:4202
> 3 	libxul.so 	js::ion::IonBuilder::makeCall 	js/src/ion/IonBuilder.cpp:4238
> 4 	libxul.so 	js::ion::IonBuilder::jsop_funapplyarguments 
> js/src/ion/IonBuilder.cpp:3870
> 5 	libxul.so 	js::ion::IonBuilder::jsop_funapply 
> js/src/ion/IonBuilder.cpp:3791

Hannes: Any idea what might go wrong here?  I sounds like the type analysis is not run the same way on fun-apply as it is for calls.

Comment 2

[Hannes Verschore [:h4writer]]

I assume this is related to bug 826148 by shu and not the fun-apply-arguments adjustments in bug 813784 I did. That bug is in the regression range and the fun-apply-arguments adjustments should already have been showing, as that was pushed on December the 22th.

In makeCallHelper there is a comment we shouldn't query TI in that function. That patch introduces queries to the oracle "oracle->getCallTarget(script(), argc, pc)" ... Could that be the problem?

Comment 3

[Shu-yu Guo [:shu]]

(In reply to Hannes Verschore [:h4writer] from comment #2)
> I assume this is related to bug 826148 by shu and not the
> fun-apply-arguments adjustments in bug 813784 I did. That bug is in the
> regression range and the fun-apply-arguments adjustments should already have
> been showing, as that was pushed on December the 22th.
> 
> In makeCallHelper there is a comment we shouldn't query TI in that function.
> That patch introduces queries to the oracle "oracle->getCallTarget(script(),
> argc, pc)" ... Could that be the problem?

That sounds possible, when is it called with a mutated stack?

Comment 4

[Shu-yu Guo [:shu]]

I see what's going on, but I don't know how to reproduce using a minimal testcase.

Comment 5

[Shu-yu Guo [:shu]]

Attachment: testcase

This is a testcase. It's kind of corner caseish, so I'm surprised this is #4.

This crash happens as h4writer pointed out, in the incorrect TI call in makeCallHelper. But usually that would only result in returning the incorrect typeset, and not a crash, except when the following stars align:

 - The callee typeset has cardinality > 1 (no known target)
 - The script with the funapply is being inlined
 - The argc of the call to the script with the funapply is > 2

What happens then is that we incorrectly try to get the popped types of a use that's out of bounds of the 2-argc funapplyarguments call.

I'll have a patch up soon.

Comment 6

[Shu-yu Guo [:shu]]

(In reply to Shu-yu Guo [:shu] from comment #5)
> Created attachment 701917 [details]
> testcase
> 
> This is a testcase. It's kind of corner caseish, so I'm surprised this is #4.
> 
> This crash happens as h4writer pointed out, in the incorrect TI call in
> makeCallHelper. But usually that would only result in returning the
> incorrect typeset, and not a crash, except when the following stars align:
> 
>  - The callee typeset has cardinality > 1 (no known target)
>  - The script with the funapply is being inlined
>  - The argc of the call to the script with the funapply is > 2
> 
> What happens then is that we incorrectly try to get the popped types of a
> use that's out of bounds of the 2-argc funapplyarguments call.
> 
> I'll have a patch up soon.

Forgot to add another condition: when the 'this' argument to the funapply is *not* 'this', as that'll actually trigger compilation on a hard-case 'this'.

Comment 7

[Shu-yu Guo [:shu]]

Attachment: fix + testcase

Patch and test case.

Threads through a StackTypeSet of the callee types. Kind of ugly, given how many makeCall helpers there are, but I couldn't come up with anything better.

Comment 8

[Shu-yu Guo [:shu]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8e7daee5f5a9

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8e7daee5f5a9