1245783 - [GCC 6] Crashes rapidly in JIT engine, jit_test.py fails

Reporter

Description

•

9 years ago

When FF is built by GCC 6 (Fedora 24, gcc-6.0.0-0.9.fc24.x86_64) it crashes 1-2 mins after start. Build with "ac_add_options --disable-ion" makes FF usable again, although there are some failed test in jit_test.py.

Firefox 44, gcc 6.0, --disable-ion, jit_test.py:

Exit code: -11
FAIL - basic/bug1118996.js
Exit code: -11
FAIL - gc/bug-1146696.js
/home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/ion/bug909997.js:31:5 Error: Assertion failed: got 0, expected 1
Stack:
  @/home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/ion/bug909997.js:31:5
Exit code: 3
FAIL - ion/bug909997.js
FAILURES:
    --fuzzing-safe --no-threads --no-ion /home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/basic/bug1118996.js
    --no-ggc /home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/gc/bug-1146696.js
    /home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/ion/bug909997.js

Trunk, gcc 6.0, --enable-ion, jit_test.py:

Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - auto-regress/bug1147907.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - basic/testGeneratorDieButScopeAlive.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Debugger-findScripts-17.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-eval-15.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-eval-27.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-eval-29.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-evalWithBindings-03.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-evalWithBindings-09.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-evalWithBindings-14.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-this-06.js
[...]
FAILURES:
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/auto-regress/bug1147907.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/basic/testGeneratorDieButScopeAlive.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Debugger-findScripts-17.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-07.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-15.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-27.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-29.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-evalWithBindings-03.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-evalWithBindings-09.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-evalWithBindings-14.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-this-06.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-this-07.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-02.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-03.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-04.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-05.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-06.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-01.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getLineOffsets-04.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1109964.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1130768.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1188334.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1232655.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/onEnterFrame-03.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/gc/bug-1104162.js

Jan de Mooij [:jandem]

Assignee

Comment 1

•

9 years ago

The isDebuggerEvalFrame assertion failure is likely bug 1246112. Debug only.

Not sure about the other failures.

Depends on: 1246112

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 2

•

9 years ago

It also crashes w/o debug enabled, in release builds we do for Fedora.

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 3

•

9 years ago

Looks like only optimized build crashes. For instance:

$./js /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit-test/tests/arguments/args4.js

Assertion failure: !isFloat(), at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/RegisterSets.h:47
(gdb) bt
#0  0x00005555557bb03c in js::jit::AnyRegister::gpr (this=this@entry=0x7fffecf19a90)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/RegisterSets.h:47
#1  0x000055555592c95a in js::jit::MacroAssembler::Push (this=this@entry=0x7ffff3cd9058, v=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/MacroAssembler.cpp:2404
#2  0x000055555592cafa in js::jit::MacroAssembler::Push (this=0x7ffff3cd9058, v=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/MacroAssembler.cpp:2414
#3  0x000055555580566c in js::jit::CodeGeneratorShared::pushArg<js::jit::ConstantOrRegister> (this=0x7ffff3cd9000, 
    this=0x7ffff3cd9000, t=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/shared/CodeGenerator-shared.h:428
#4  js::jit::CodeGenerator::visitGetPropertyIC (this=0x7ffff3cd9000, ool=0x7fffeb01bf80, ic=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/CodeGenerator.cpp:8548
#5  0x00005555558058b6 in js::jit::OutOfLineUpdateCache::visitGetPropertyIC (this=<optimized out>, codegen=<optimized out>)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/CodeGenerator.cpp:106
#6  0x00005555559a9dc3 in js::jit::CodeGeneratorShared::generateOutOfLineCode (this=this@entry=0x7ffff3cd9000)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/shared/CodeGenerator-shared.cpp:182
#7  0x0000555555a0c2d9 in js::jit::CodeGeneratorX86Shared::generateOutOfLineCode (this=this@entry=0x7ffff3cd9000)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/x86-shared/CodeGenerator-x86-shared.cpp:409
#8  0x000055555580de20 in js::jit::CodeGenerator::generate (this=this@entry=0x7ffff3cd9000)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/CodeGenerator.cpp:7907
#9  0x000055555581fdca in js::jit::GenerateCode (mir=mir@entry=0x7fffeb018270, lir=0x7fffeb01a480)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/Ion.cpp:1950
#10 0x000055555587fa58 in js::jit::CompileBackEnd (mir=mir@entry=0x7fffeb018270)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/Ion.cpp:1972
#11 0x0000555555be4544 in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/vm/HelperThreads.cpp:1294
#12 0x0000555555be7937 in js::HelperThread::threadLoop (this=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/vm/HelperThreads.cpp:1612
#13 0x00007ffff4f955db in _pt_root (arg=0x7ffff3c49380) at ../../../nspr/pr/src/pthreads/ptthread.c:212
#14 0x00007ffff7bc169a in start_thread (arg=0x7fffecf1a700) at pthread_create.c:333
#15 0x00007ffff41e4dbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Martin Stránský [:stransky] (ni? me)

Reporter

Updated

•

8 years ago

Blocks: 1253216

Nicolas B. Pierron [:nbp]

Comment 4

•

8 years ago

My blind guess would be the same as what happened with gcc4.9, which is that gcc developers made some optimizations, which are not working as expected when used on our code base.

Would it be possible to bisect the set of compiler flags which are required to make the JS shell crash?

Flags: needinfo?(stransky)

Martin Liška

Comment 5

•

8 years ago

Well, I suspect -flifetime-dse=2 (default option with -O1 and above), aka: https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c6

Thus I would try to add following flags to the default ones:
-flifetime-dse=1
-fno-delete-null-pointer-checks

Maybe there would be another problematic option:
https://gcc.gnu.org/gcc-6/porting_to.html

Martin

Nicolas B. Pierron [:nbp]

Comment 6

•

8 years ago

(In reply to Martin Liška from comment #5)
> Well, I suspect -flifetime-dse=2 (default option with -O1 and above), aka:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c6

Indeed, this kind of initialization is used by the allocator used in IonMonkey.  Still, we should consider it as a bug if we do not initialized these values our-self.

I guess we could change the pattern used for initializing the LifoAlloc used by IonMonkey and make sure that we properly initialize the memory after the fact.

Idependently of the placement new, I think we are doing the same kind of  memset  in the constructor of JSScript, which is a central point of the JS engine.

(In reply to Martin Liška from comment #5)
> -fno-delete-null-pointer-checks

I do not recall seeing any code which can have a null "this" pointer in our code base.

Martin Liška

Comment 7

•

8 years ago

(In reply to Nicolas B. Pierron [:nbp] from comment #6)
> (In reply to Martin Liška from comment #5)
> > Well, I suspect -flifetime-dse=2 (default option with -O1 and above), aka:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c6
> 
> Indeed, this kind of initialization is used by the allocator used in
> IonMonkey.  Still, we should consider it as a bug if we do not initialized
> these values our-self.
> 
> I guess we could change the pattern used for initializing the LifoAlloc used
> by IonMonkey and make sure that we properly initialize the memory after the
> fact.
> 
> Idependently of the placement new, I think we are doing the same kind of 
> memset  in the constructor of JSScript, which is a central point of the JS
> engine.
> 
> (In reply to Martin Liška from comment #5)
> > -fno-delete-null-pointer-checks
> 
> I do not recall seeing any code which can have a null "this" pointer in our
> code base.

Please check UBSAN output here: https://bugzilla.mozilla.org/show_bug.cgi?id=996026#c3
I see couple of this pointer being null in the report

Martin

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 8

•

8 years ago

I see the same JIT crashes when built with -flifetime-dse=1.

Flags: needinfo?(stransky)

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 9

•

8 years ago

JIT also crashes with both -flifetime-dse=1 -fno-delete-null-pointer-checks.

Makoto Kato [:m_kato]

Updated

•

8 years ago

Blocks: 1257055

Jan de Mooij [:jandem]

Assignee

Comment 11

•

8 years ago

I can reproduce this with an --enable-debug --enable-optimize Linux x64 shell build.

    g++-6 (Ubuntu 6-20160319-0ubuntu11) 6.0.0 20160319 (experimental) [trunk revision 234350]

GCC 6 is miscompiling (the last part of) CodeGenerator::toConstantOrRegister:

    return TypedOrValueRegister(type, ToAnyRegister(value));

Annotated assembly below:

callq  0x617d30 <js::jit::ToAnyRegister(js::jit::LAllocation const&)>

// Get pointer to TypedOrValueRegister.
lea    -0x40(%rbp),%rdi

// Move ToAnyRegister return value to r13d.
mov    %eax,%r13d

// Store TypedOrValueRegister type_.
mov    %r12d,-0x40(%rbp)

callq  0x65aec0 <js::jit::TypedOrValueRegister::dataTyped()>

// ---> This load is bogus. I think GCC attempts to load the AnyRegister value stored
// to the TypedOrValueRegister pointer we just loaded, but it was never stored there
// so we read uninitialized memory.
mov    -0x38(%rbp),%rdx

// Store AnyRegister to dataTyped() return value.
mov    %r13d,(%rax)

// Load TypedOrValueRegister::type_ into rax.
mov    -0x40(%rbp),%rax

// ConstantOrRegister constructor.
// ---> this uses the bogus value in rdx
movb   $0x0,(%rbx)      // constant_ = false
mov    %rdx,0x10(%rbx)  // store TypedOrValueRegister data
mov    %rax,0x8(%rbx)   // store TypedOrValueRegister type_

mov    -0x28(%rbp),%rcx
xor    %fs:0x28,%rcx
mov    %rbx,%rax
jne    0x61edc1 <js::jit::CodeGenerator::toConstantOrRegister(js::jit::LInstruction*, unsigned long, js::jit::MIRType)+209>
add    $0x28,%rsp
pop    %rbx
pop    %r12
pop    %r13
pop    %rbp
retq

Martin Liška

Comment 12

•

8 years ago

Can you please isolate the function and create a PR for GCC?

Thanks,
Martin

Jan de Mooij [:jandem]

Assignee

Comment 13

•

8 years ago

(In reply to Jan de Mooij [:jandem] from comment #11)

I forgot to mention that the bogus load here:

  mov    -0x38(%rbp),%rdx

Reads memory that's initialized by the next instruction:

  // Store AnyRegister to dataTyped() return value.
  mov    %r13d,(%rax)

(If the second instruction came before the first, everything would be fine probably.)

Jan de Mooij [:jandem]

Assignee

Comment 14

•

8 years ago

(In reply to Martin Liška from comment #12)
> Can you please isolate the function and create a PR for GCC?

I'll try that next, but I've no idea how hard it will be and I've other bugs to work on..

Jan de Mooij [:jandem]

Assignee

Comment 15

•

8 years ago

I filed a GCC bug with a minimal testcase:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 16

•

8 years ago

gcc-6.0.0-0.20.fc24.x86_64 on Fedora 24 should contain a fix for 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 bug JS keeps crashing when JIT is enabled (and so Firefox). 

But the crash-rate is much better and also the JIT test produces less errors then before, but some test still fails with a crash. Can anyone else confirm the fix?

Jan de Mooij [:jandem]

Assignee

Comment 17

•

8 years ago

(In reply to Martin Stránský from comment #16)
> But the crash-rate is much better and also the JIT test produces less errors
> then before, but some test still fails with a crash. Can anyone else confirm
> the fix?

Do you have a stack trace for this? Does an --enable-debug --enable-optimize build also fail?

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 18

•

8 years ago

It's easy to reproduce from the jit-tests.

for instance js js/src/jit-test/tests/auto-regress/bug675251.js crashes right away.

bt:

#0  0x00007ffff3c5b800 in ?? ()
#1  0x00005555557ef3a7 in js::jit::SnapshotIterator::numAllocations (this=0x7fffffefdf00)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:2159
#2  js::jit::IonFrameStackDepthOp::IonFrameStackDepthOp (frame=..., this=<optimized out>)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:421
#3  js::jit::TryNoteIterIon::TryNoteIterIon (frame=..., cx=0x7ffff3c19000, this=0x7fffffefdec0)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:431
#4  js::jit::HandleExceptionIon (overrecursed=0x7fffffefddaf, rfe=0x7fffffefe368, frame=..., cx=0x7ffff3c19000)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:478
#5  js::jit::HandleException (rfe=0x7fffffefe368)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:853
#6  0x00007ffff7fe6162 in ?? ()
#7  0x00007fffeb2c8740 in ?? ()
#8  0x00007fffffefe368 in ?? ()
#9  0x00007ffffffec7c0 in ?? ()
#10 0x0000000000000000 in ?? ()

Comment hidden (obsolete)

Backtrace from Firefox, if it helps:

#0  0x00007fffe9e95b2d in js::jit::HandleException(js::jit::ResumeFromException*) (frame=..., this=<optimized out>)
    at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:421
#1  0x00007fffe9e95b2d in js::jit::HandleException(js::jit::ResumeFromException*) (frame=..., cx=0x7fffdb586800, this=0x7fffffff7440) at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:431
#2  0x00007fffe9e95b2d in js::jit::HandleException(js::jit::ResumeFromException*) (overrecursed=0x7fffffff732f, rfe=0x7fffffff78e8, frame=..., cx=0x7fffdb586800) at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:478
#3  0x00007fffe9e95b2d in js::jit::HandleException(js::jit::ResumeFromException*) (rfe=0x7fffffff78e8)
        at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:853
#4  0x00007ffff7fd5162 in  ()
#5  0x00007fffffff79e0 in  ()
#6  0x00007fffffff78e8 in  ()
#7  0x00007fffffff7db0 in  ()
#8  0x0000000000000404 in  ()
#9  0x00007ffff7fd5680 in  ()
#10 0x00007ffff7fd9862 in  ()
#11 0x00007fff00000000 in  ()
#12 0x00007fffffff7918 in  ()
#13 0x0000000000000000 in  ()

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 20

•

8 years ago

Correct FF backtrace, looks like the one from jit-tests:

(gdb) up
#1  js::jit::TryNoteIterIon::TryNoteIterIon (frame=..., cx=0x7fffdb586800, this=0x7fffffff7440)
    at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:431
#2  js::jit::HandleExceptionIon (overrecursed=0x7fffffff732f, rfe=0x7fffffff78e8, frame=..., cx=0x7fffdb586800)
    at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:478
#3  js::jit::HandleException (rfe=0x7fffffff78e8)
    at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:853

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 21

•

8 years ago

--enable-debug, --enable-optimize produces this crash, actually the same as in comment 3:

46	    Register gpr() const {
47	        MOZ_ASSERT(!isFloat());
48	        return Register::FromCode(code_);

#0  js::jit::AnyRegister::gpr (this=<optimized out>)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/RegisterSets.h:47
#1  js::jit::MacroAssembler::storeTypedOrValue<js::jit::Address> (dest=..., src=..., this=0x7ffff3cc8058)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/MacroAssembler.h:900
#2  js::jit::MacroAssembler::storeConstantOrRegister<js::jit::Address> (this=0x7ffff3cc8058, src=..., dest=...)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/MacroAssembler.h:920
#3  0x000055555583f1f1 in js::jit::CodeGenerator::visitStoreFixedSlotT (this=0x7ffff3cc8000, ins=<optimized out>)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/CodeGenerator.cpp:8580
#4  0x0000555555856ac7 in js::jit::CodeGenerator::generateBody (this=this@entry=0x7ffff3cc8000)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/CodeGenerator.cpp:4263
#5  0x0000555555857886 in js::jit::CodeGenerator::generate (this=this@entry=0x7ffff3cc8000)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/CodeGenerator.cpp:7999
#6  0x0000555555864b3a in js::jit::GenerateCode (mir=mir@entry=0x7fffeb11a270, lir=0x7fffeb11be38)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/Ion.cpp:1974
#7  0x00005555558bdb44 in js::jit::CompileBackEnd (mir=mir@entry=0x7fffeb11a270)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/Ion.cpp:1996
#8  0x0000555555c23114 in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/vm/HelperThreads.cpp:1264
#9  0x0000555555c26a87 in js::HelperThread::threadLoop (this=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/vm/HelperThreads.cpp:1582
#10 0x00007ffff4f997df in _pt_root (arg=0x7ffff3c6a380) at ../../../nspr/pr/src/pthreads/ptthread.c:216
#11 0x00007ffff7bc458a in start_thread (arg=0x7fffed08c700) at pthread_create.c:333
#12 0x00007ffff41ee5cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Mike Hommey [:glandium]

Comment 22

•

8 years ago

This is what building with GCC 6.1 looks on automation:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=20df2b5901930713f5a14504121545ce235da18f

It's not pretty.

This is the tooltool manifest change required to use GCC 6.1 on automation for anyone who would want to try it some more:
https://hg.mozilla.org/try/diff/20df2b590193/browser/config/tooltool-manifests/linux64/releng.manifest

I didn't try to disable lifetime DSE yet.

Mike Hommey [:glandium]

Comment 23

•

8 years ago

It looks equally bad with -fno-lifetime-dse -fno-delete-null-pointer-checks:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=86d7709526d4ddacaac38fd3b31cbdb0b900b2a6

Jan de Mooij [:jandem]

Assignee

Comment 24

•

8 years ago

I'll take another look at this. If it turns out to be another GCC 6 bug that will be disappointing though...

Jan de Mooij [:jandem]

Assignee

Comment 25

•

8 years ago

The crash is very similar to the last one, and my original test case for the GCC bug still fails. It looks like either it wasn't fixed completely, or there is also a problem in our code.

Julian Seward [:jseward]

Comment 26

•

8 years ago

Jan, can you try the patch at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c16 ?

Jan de Mooij [:jandem]

Assignee

Comment 27

•

8 years ago

(In reply to Julian Seward [:jseward] from comment #26)
> Jan, can you try the patch at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c16 ?

I'm building and testing just the JS shell, so no xpcom :)

Jan de Mooij [:jandem]

Assignee

Updated

•

8 years ago

Depends on: 1269319

u403884

Comment 29

•

8 years ago

I cannot see how CodeGenerator::toConstantOrRegister() (see Comment 11) is executed within the stack trace reported at Comment 21 and in Bug 1272944.

Also gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 that has been opened from this bug does not seem to propose a valid fix with respect to this bug, despite being currently marked as RESOLVED FIXED.

Debugging and resolution of this problem do not seem to me on the right track...

u403884

Comment 30

•

8 years ago

What I found useful is https://bugzilla.mozilla.org/show_bug.cgi?id=1218925#c1

u403884

Comment 31

•

8 years ago

However, I found that the referenced gcc bug provides a possible workaround: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526#c14

So, I am testing the following Makefile patch with gcc6 and it seems to build a working firefox:

--- firefox-45.0.1-orig/js/src/Makefile.in	2016-05-17 14:53:58.753178403 +0200
+++ firefox-45.0.1/js/src/Makefile.in	2016-05-17 14:53:28.432817862 +0200
@@ -144,6 +144,11 @@ distclean::
 
 CFLAGS += $(MOZ_ZLIB_CFLAGS)
 
+# Avoid GNU gcc bug #70526
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526#c14
+CFLAGS += -fno-schedule-insns2
+CXXFLAGS += -fno-schedule-insns2
+
 # Silence warnings on AIX/HP-UX from non-GNU compilers
 ifndef GNU_CC
 ifeq ($(OS_ARCH),AIX)

Martin Stránský [:stransky] (ni? me)

Reporter

Comment 32

•

8 years ago

With the "-fno-schedule-insns2" the jit-test passes cleanly, Thanks!

Mike Hommey [:glandium]

Comment 33

•

8 years ago

Try seems to say we're good with "-fno-schedule-insns2 -fno-delete-null-pointer-checks" (-fno-schedule-insns2 still has plenty of broken tests):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=19e8885a104a5ef99cbd0d4a3ad0305f96cfff2a

Jan de Mooij [:jandem]

Assignee

Comment 34

•

8 years ago

Would you mind waiting till I land bug 1269319? I hope that will take care of at least the 'schedule-insns2' failures...

I'll try to get that landed today.

Jan de Mooij [:jandem]

Assignee

Updated

•

8 years ago

Depends on: 1269317

Jan de Mooij [:jandem]

Assignee

Comment 35

•

8 years ago

jit-tests pass for me with GCC 6 + the patches for bug 1269319 and bug 1245783.

I'll try to get those backported.

Jan de Mooij [:jandem]

Assignee

Comment 36

•

8 years ago

(In reply to Jan de Mooij [:jandem] from comment #35)
> jit-tests pass for me with GCC 6 + the patches for bug 1269319 and bug
> 1245783.

Er, bug 1269319 and bug 1269317.

Jan de Mooij [:jandem]

Assignee

Updated

•

8 years ago

Flags: needinfo?(jdemooij)

Jan de Mooij [:jandem]

Assignee

Comment 38

•

8 years ago

Requested uplift of bug 1269319 and bug 1269317 to Aurora and ESR45.

Marking this fixed as the JS tests pass now.

Assignee: nobody → jdemooij

Status: NEW → RESOLVED

Closed: 8 years ago

Flags: needinfo?(jdemooij)

Resolution: --- → FIXED

Target Milestone: --- → mozilla49

Julian Seward [:jseward]

Updated

•

8 years ago

Blocks: 1316555