1041472 - [b2g] Crash at src/js/src/jit/arm/Assembler-arm.cpp:788, TraceJumpRelocations on Nexus-5

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect)

Description

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

STR: b2g crash after launching homescreen app
Gecko: e743fd8c57ed

Program received signal SIG36, Real-time event 36.
[Switching to Thread 1810.1864]
notify_gdb_of_load (info=0xb6b006dc) at bionic/linker/linker.cpp:234
234         rtld_db_dlactivity();
(gdb) c
Continuing.
[New Thread 1810.1848]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1810.1848]
js::jit::Assembler::TraceJumpRelocations (trc=trc@entry=0xb0aea898, 
    code=code@entry=0xafaa8510, reader=...)
    at ../../../../../workspace1/central/src/js/src/jit/arm/Assembler-arm.cpp:788
788         while (iter.read()) {

Comment 1

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I'm not sure it's related to kitkat, but it looks like 100% reproducible on my Nexus5.

Comment 2

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

#0  js::jit::Assembler::TraceJumpRelocations (trc=trc@entry=0xb0ac1898, code=code@entry=0xaf8e8330, reader=...) at ../../../../../workspace1/central/src/js/src/jit/arm/Assembler-arm.cpp:788
        iter = {reader_ = {buffer_ = <optimized out>, end_ = 0xad9571a8 "0\240"}, offset_ = <optimized out>}
#1  0xb5bec6ee in js::jit::JitCode::trace (this=this@entry=0xaf8e8330, trc=trc@entry=0xb0ac1898) at ../../../../../workspace1/central/src/js/src/jit/Ion.cpp:757
        start = <optimized out>
        reader = {buffer_ = 0xad9571a0 "\t\004Y\004\261\004\031\006\060\240", end_ = 0xad9571a8 "0\240"}
#2  0xb5b83aac in MarkChildren (code=0xaf8e8330, trc=0xb0ac1898) at ../../../../../workspace1/central/src/js/src/gc/Marking.cpp:1422
No locals.
#3  processMarkStackOther (addr=2945352496, tag=5, this=<optimized out>) at ../../../../../workspace1/central/src/js/src/gc/Marking.cpp:1597
No locals.
#4  processMarkStackTop (budget=..., this=0xb0ac1898) at ../../../../../workspace1/central/src/js/src/gc/Marking.cpp:1635
        vp = <optimized out>
        end = <optimized out>
        obj = <optimized out>
        addr = 2945352496
        tag = 5

Comment 3

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

hg backout -r 194555
It seems that no longer crash.

Comment 4

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Sorry, I didn't mention that it happens on m-c branch.

Comment 5

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

STR:
After entering homescreen, scroll homescreen and it crashed and code stack can be seen 1041472. My environment is Nexus-5 (Kikat based).

If you need anything else, just let me know.

Comment 6

[Douglas Crosher [:dougc]]

Testing of b2g on the Flame (debug), Flame (no-debug), Nexus4-kk (debug), Nexus4-kk (no-debug) did not reproduce a crash with this signature.

However while testing another crash found in the above testing it was found, that when running b2g with gdb connected for debugging, that a SIGSEGV with the same signature as reported above was reproducible.

But this was an expected SIGSEGV and was continuable. The ARM backend now uses memory protection of JIT executable code to interrupt JIT execution, see bug 964258.

Could you please confirm if a crash with this signature was seen without gdb attached?

If it was only seen with gdb attached then was it continuable?

Comment 7

[Douglas Crosher [:dougc]]

Should note the revision tested, comment 6, was e5ced39f443b.

Comment 8

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Yes. Sometimes with gdb attached even we got SIGSEGV, it was continuable to execute further. But sometimes it still crashed with the same signature (even gdb attached), which is conflict with the fact in bug 964258. I will test again with minidump enabled to make sure I delivered the correct message. Btw, my environment is Nexus-5 (no-debug b2g build) Kitkat.

Comment 9

[Thomas Zimmermann [:tzimmermann] [:tdz]]

The SIGSEGV described in comment 6 sounds like the crash I observed. I could always continue execution and I don't remember seeing it crash without gdb connected.

Comment 10

[Benjamin Bouvier [:bbouvier] (inactive)]

For what it's worth, running gdb with the env variable JS_NO_SIGNALS=1 will disable the use of SIGSEGV in the JITs, but won't disable slow script dialogs. If the segfault you're experiencing can be continued without issues, using JS_NO_SIGNALS=1 will definitely help you debugging.

Comment 11

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

The latest code works. So close it.