Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#20381 closed defect (fixed)

Tor Browser nightly bundles crash on Linux 64bit systems

Reported by: gk Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Critical Keywords: tbb-crash, TorBrowserTeam201610, GeorgKoppen201610
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

A couple of hours ago I hit a crash which is reproducible with the following backtrace:

Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
0x00007ffff3e2cbe1 in js::jit::SnapshotIterator::numAllocations (
    this=0x7fffffff6200)
    at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:2159
2159	/home/debian/build/tor-browser/js/src/jit/JitFrames.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x00007ffff3e2cbe1 in js::jit::SnapshotIterator::numAllocations (
    this=0x7fffffff6200)
    at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:2159
#1  js::jit::IonFrameStackDepthOp::IonFrameStackDepthOp (frame=..., 
    this=<optimized out>)
    at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:421
#2  js::jit::TryNoteIterIon::TryNoteIterIon (frame=..., cx=0x7fffdf71d800, 
    this=0x7fffffff61c0)
    at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:431
#3  js::jit::HandleExceptionIon (overrecursed=0x7fffffff60af, rfe=0x7fffffff6660, 
    frame=..., cx=0x7fffdf71d800)
    at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:478
#4  js::jit::HandleException (rfe=0x7fffffff6660)
    at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:853

We did not change anything recently JIT code related.

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by gk

It turns out this is GCC 6 related. Mozilla provided patches in bug

https://bugzilla.mozilla.org/show_bug.cgi?id=1269317 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1269319

which fixed the problem. They did not get backported to ESR45/Aurora, though, as they caused other build bustages, with MSVC and while doing builds for Android. We could think about trying to backport those fixes ourselves but builds with GCC 6 still seem to be broken until

https://bugzilla.mozilla.org/show_bug.cgi?id=1232696

gets fixed. Thus, this will be too unstable to get into 6.5. We should aim for Tor Browser 7.0 earliest for GCC 6. Unfortunately, this means EMET support (#13893) will need to wait for another while :(

comment:2 Changed 3 years ago by gk

Resolution: fixed
Status: newclosed

Backing out the patch for #13893 with commit 48b0c33bf651baaaa972e81490b3896dd332437e and thus reverting GCC back to 5.1.0

comment:3 Changed 3 years ago by mcs

I am not a compiler expert, but it surprises me that -flifetime-dse=1 or -fno-lifetime-dse does not make the problem disappear. But https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c11 says otherwise. Maybe there are problems with gcc 6 that Mozilla does not understand yet.

Last edited 3 years ago by mcs (previous) (diff)

comment:4 in reply to:  2 Changed 3 years ago by gk

Replying to gk:

Backing out the patch for #13893 with commit 48b0c33bf651baaaa972e81490b3896dd332437e and thus reverting GCC back to 5.1.0

FWIW: I'll back out the Mozilla patches needed for compiling with GCC 6 when rebasing to Firefox 45.5.0esr.

Note: See TracTickets for help on using tickets.