Closed
Bug 1245783
Opened 9 years ago
Closed 9 years ago
[GCC 6] Crashes rapidly in JIT engine, jit_test.py fails
Categories
(Core :: JavaScript Engine: JIT, defect)
Core
JavaScript Engine: JIT
Tracking
()
RESOLVED
FIXED
mozilla49
Tracking | Status | |
---|---|---|
firefox47 | --- | affected |
People
(Reporter: stransky, Assigned: jandem)
References
Details
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
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
Reporter | ||
Comment 2•9 years ago
|
||
It also crashes w/o debug enabled, in release builds we do for Fedora.
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
Comment 4•9 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)
Comment 5•9 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
Comment 6•9 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.
Comment 7•9 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
Reporter | ||
Comment 8•9 years ago
|
||
I see the same JIT crashes when built with -flifetime-dse=1.
Flags: needinfo?(stransky)
Reporter | ||
Comment 9•9 years ago
|
||
JIT also crashes with both -flifetime-dse=1 -fno-delete-null-pointer-checks.
Assignee | ||
Comment 11•9 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
Comment 12•9 years ago
|
||
Can you please isolate the function and create a PR for GCC?
Thanks,
Martin
Assignee | ||
Comment 13•9 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.)
Assignee | ||
Comment 14•9 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..
Assignee | ||
Comment 15•9 years ago
|
||
I filed a GCC bug with a minimal testcase:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
Reporter | ||
Comment 16•9 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?
Assignee | ||
Comment 17•9 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?
Reporter | ||
Comment 18•9 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) |
Reporter | ||
Comment 20•9 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
Reporter | ||
Comment 21•9 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
Comment 22•9 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.
Comment 23•9 years ago
|
||
It looks equally bad with -fno-lifetime-dse -fno-delete-null-pointer-checks:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=86d7709526d4ddacaac38fd3b31cbdb0b900b2a6
Assignee | ||
Comment 24•9 years ago
|
||
I'll take another look at this. If it turns out to be another GCC 6 bug that will be disappointing though...
Assignee | ||
Comment 25•9 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.
Comment 26•9 years ago
|
||
Jan, can you try the patch at
https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c16 ?
Assignee | ||
Comment 27•9 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 :)
Comment 29•9 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...
Comment 30•9 years ago
|
||
What I found useful is https://bugzilla.mozilla.org/show_bug.cgi?id=1218925#c1
Comment 31•9 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)
Reporter | ||
Comment 32•9 years ago
|
||
With the "-fno-schedule-insns2" the jit-test passes cleanly, Thanks!
Comment 33•9 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
Assignee | ||
Comment 34•9 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.
Assignee | ||
Comment 35•9 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.
Assignee | ||
Comment 36•9 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.
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(jdemooij)
Assignee | ||
Comment 38•9 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: 9 years ago
Flags: needinfo?(jdemooij)
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in
before you can comment on or make changes to this bug.
Description
•