[aarch64-port-dev ] Issue with turning off UseOnStackReplacement with TieredCompilation

Andy Johnson andy.johnson at linaro.org
Tue Feb 11 08:35:59 PST 2014


(gdb) c
Continuing.
Hardware watchpoint 1: *0x7fa1098c78

Old value = -858993460
New value = 1409286144
0x0000007fb70cf478 in emit_int32 (x=1409286144, this=0x7fb6d1afc0)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/asm/codeBuffer.hpp:197
197
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/asm/codeBuffer.hpp: No
such file or directory.
(gdb) where
#0  0x0000007fb70cf478 in emit_int32 (x=1409286144, this=0x7fb6d1afc0)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/asm/codeBuffer.hpp:197
#1  emit_int32 (x=1409286144, this=0x7fb000c0a8)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/asm/assembler.hpp:280
#2  emit_long (x=1409286144, this=0x7fb000c0a8)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/assembler_aarch64.hpp:611
#3  Assembler::emit (this=0x7fb000c0a8)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/assembler_aarch64.hpp:667
#4  0x0000007fb7171590 in ~Instruction_aarch64 (this=0x7fb6d1ab10,
    __in_chrg=<optimized out>)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/assembler_aarch64.hpp:1992
#5  Assembler::br (this=this at entry=0x7fb000c0a8,
    cond=cond at entry=Assembler::EQ, dest=<optimized out>)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/assembler_aarch64.hpp:878
#6  0x0000007fb716ae30 in Assembler::br (this=0x7fb000c0a8,
cc=Assembler::EQ,
    L=...)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/assembler_aarch64.cpp:1377
#7  0x0000007fb716ae98 in Assembler::br (this=this at entry=0x7fb000c0a8,
    cc=cc at entry=Assembler::EQ, L=...)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/assembler_aarch64.cpp:1379
#8  0x0000007fb75e89ac in
InterpreterMacroAssembler::increment_mask_and_jump (
    this=0x7fb000c0a8, counter_addr=..., increment=increment at entry=8,
    mask=mask at entry=8184, scratch=scratch at entry=0x0,
    preloaded=preloaded at entry=false, cond=cond at entry=Assembler::EQ,
    where=where at entry=0x7fb6d1ace0)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/interp_masm_aarch64.cpp:1425
#9  0x0000007fb7a560c0 in TemplateTable::branch (is_jsr=<optimized out>,
    is_wide=<optimized out>)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/templateTable_aarch64.cpp:1663
#10 0x0000007fb7a4ad14 in Template::generate (
    this=this at entry=0x7fb7ddd9b8 <TemplateTable::_template_table+5344>,
    masm=<optimized out>)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/interpreter/templateTable.cpp:68
#11 0x0000007fb7a407fc in
TemplateInterpreterGenerator::generate_and_dispatch
    (this=this at entry=0x7fb6d1b660,
    t=t at entry=0x7fb7ddd9b8 <TemplateTable::_template_table+5344>,
    tos_out=tos_out at entry=ilgl)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/interpreter/templateInterpreter.cpp:530
#12 0x0000007fb7a447ac in
TemplateInterpreterGenerator::set_vtos_entry_points
    (this=0x7fb6d1b660, t=0x7fb7ddd9b8
<TemplateTable::_template_table+5344>,
    bep=@0x7fb6d1b2a0: 0x7fa1098b00 "\200\216\037\370\240\003^\370",
    cep=@0x7fb6d1b290: 0x7fa1098b00 "\200\216\037\370\240\003^\370",
    sep=@0x7fb6d1b280: 0x7fa1098b00 "\200\216\037\370\240\003^\370",
    aep=<optimized out>,
    iep=@0x7fb6d1b260: 0x7fa1098b00 "\200\216\037\370\240\003^\370",
    lep=@0x7fb6d1b250: 0x7fa1098af8 "\200\016\037\370\002",
    fep=@0x7fb6d1b240: 0x7fa1098ae8 "\200\216\037\274\006",
    dep=@0x7fb6d1b230: 0x7fa1098af0 "\200\016\037\374\004",
    vep=@0x7fb6d1b220: 0x7fa1098b04 "\240\003^\370")
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp:1804
#13 0x0000007fb7a4159c in TemplateInterpreterGenerator::set_entry_points (
    this=this at entry=0x7fb6d1b660, code=code at entry=Bytecodes::_goto)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/interpreter/templateInterpreter.cpp:464
#14 0x0000007fb7a417f0 in
TemplateInterpreterGenerator::set_entry_points_for_all_bytes
(this=this at entry=0x7fb6d1b660)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/interpreter/templateInterpreter.cpp:421
#15 0x0000007fb7a43a6c in TemplateInterpreterGenerator::generate_all (
    this=0x7fb6d1b660)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/interpreter/templateInterpreter.cpp:402
#16 0x0000007fb7a44018 in TemplateInterpreter::initialize ()
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/interpreter/templateInterpreter.cpp:52
#17 0x0000007fb75eb14c in interpreter_init ()
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/interpreter/interpreter.cpp:118
#18 0x0000007fb7578d08 in init_globals ()
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/runtime/init.cpp:107
#19 0x0000007fb7a6bb30 in Threads::create_vm (args=args at entry=0x7fb6d1b9a0,
    canTryAgain=canTryAgain at entry=0x7fb6d1b920)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/runtime/thread.cpp:3424
#20 0x0000007fb763e0f8 in JNI_CreateJavaVM (vm=0x7fb6d1b9c0,
    penv=0x7fb6d1b9b8, args=0x7fb6d1b9a0)
    at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jni.cpp:5166
#21 0x0000007fb7f68b30 in JavaMain ()
   from
/home/andy/images/j2sdk-image-140207-fd/bin/../lib/aarch64/jli/libjli.so
#22 0x0000007fb7fb0b08 in start_thread (arg=0x7fb6d1c210)
    at pthread_create.c:313
#23 0x0000007fb7ed278c in clone () from /lib/aarch64-linux-gnu/libc.so.6
#24 0x0000007fb7ed278c in clone () from /lib/aarch64-linux-gnu/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) x/i 0x7fa1098c78
   0x7fa1098c78:    b.eq    0x7fa1098c78

The code at
/home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/assembler_aarch64.cpp:1377
generates a "branch on condition to self", but sets up a pending patch to
modify the branch target once it is determined (i.e. a forward branch).
However, it looks like the pending patch never gets applied before the
instruction is executed.



On 11 February 2014 11:12, Edward Nevill <edward.nevill at linaro.org> wrote:

> On Tue, 2014-02-11 at 09:49 -0500, Andy Johnson wrote:
> > (gdb) x/20i $pc-40
> >    0x7fa1098c50:    add    x0, x0, #0x8
> >    0x7fa1098c54:    str    x0, [x1,#112]
> >    0x7fa1098c58:    ands    x0, x0, #0x1ff8
> >    0x7fa1098c5c:    b.eq    0x7fa1098c5c
> >    0x7fa1098c60:    b    0x7fa1098c7c
> >    0x7fa1098c64:    ldr    x8, [x12,#32]
> >    0x7fa1098c68:    ldr    x0, [x8,#12]
> >    0x7fa1098c6c:    add    x0, x0, #0x8
> >    0x7fa1098c70:    str    x0, [x8,#12]
> >    0x7fa1098c74:    ands    x0, x0, #0x1ff8
> > => 0x7fa1098c78:    b.eq    0x7fa1098c78
>
> Andy,
>
> I think you will find the above instruction to be the source of the
> problem.
>
> Now you need to find what generated this instruction.
>
> Run the program to this point again. Then set watchpoint on the location
>
> IE.
>
> wa *0x7fa1098c78
>
> Then run the program again, no need to specify the args again, just the
> run command on its own.
>
> run
>
> The watchpoint will trigger a couple of times (in memset). Each time it
> triggers disassemble the location to see has it written the above
> instruction
>
> so
>
> x/i 0x7fa1098c5c
>
> When you see the instruction having just been written use the 'up' command
> to step back up the stack to find out what piece of code is generating this.
>
> Regards,
> Ed.
>
> >    0x7fa1098c7c:    ldrb    w8, [x22]
> >    0x7fa1098c80:    add    w9, w8, #0x800
> >    0x7fa1098c84:    ldr    x9, [x21,w9,uxtw #3]
> >    0x7fa1098c88:    br    x9
> >    0x7fa1098c8c:    str    x22, [x29,#-56]
> >    0x7fa1098c90:    ldr    x8, [x29,#-16]
> >    0x7fa1098c94:    cbz    x8, 0x7fa1098d08
> >    0x7fa1098c98:    stp    x30, xzr, [sp,#-16]!
> >    0x7fa1098c9c:    stp    x28, x29, [sp,#-16]!
> >
> >
> > BTW, it also hangs when run under the slowdebug simulator.  This is
> > thread 2:
> > (gdb) thread 2
> > [Switching to thread 2 (Thread 0x7ffff563d700 (LWP 15035))]
> > #0  0x00007ffff5b69cb1 in CPUState::updatePC (this=0x7ffff001c510)
> >     at cpustate.cpp:67
> > 67      trace_buffer[trace_counter++ % trace_size] = pc;
> > (gdb) where
> > #0  0x00007ffff5b69cb1 in CPUState::updatePC (this=0x7ffff001c510)
> >     at cpustate.cpp:67
> > #1  0x00007ffff5b87dae in AArch64Simulator::run (this=0x7ffff001c510)
> >     at simulator.cpp:344
> > #2  0x00007ffff62827fa in setup_arm_sim (sp=0x7ffff563b320,
> > calltype=8)
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/aarch64_call.cpp:173
> > #3  0x00007ffff62829ec in aarch64_prolog ()
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/aarch64_linkage.S:112
> > #4  0x00007ffff6760932 in JavaCalls::call_helper
> > (result=0x7ffff563b940,
> >     m=0x7ffff563b820, args=0x7ffff563b6e0,
> > __the_thread__=0x7ffff000c4e8)
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/runtime/javaCalls.cpp:406
> > #5  0x00007ffff69bd31c in os::os_exception_wrapper (
> >     f=0x7ffff67602a2 <JavaCalls::call_helper(JavaValue*,
> > methodHandle*, JavaCallArguments*, Thread*)>, value=0x7ffff563b940,
> > method=0x7ffff563b820,
> >     args=0x7ffff563b6e0, thread=0x7ffff000c4e8)
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/hotspot/src/os/linux/vm/os_linux.cpp:5119
> > #6  0x00007ffff67602a0 in JavaCalls::call (result=0x7ffff563b940,
> > method=...,
> >     args=0x7ffff563b6e0, __the_thread__=0x7ffff000c4e8)
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/runtime/javaCalls.cpp:307
> > ---Type <return> to continue, or q <return> to quit---
> > #7  0x00007ffff6774614 in jni_invoke_nonstatic (env=0x7ffff000c6f8,
> >     result=0x7ffff563b940, receiver=0x7ffff00fd4a0,
> > call_type=JNI_NONVIRTUAL,
> >     method_id=0x7ffff010fee8, args=0x7ffff563b8f0,
> >     __the_thread__=0x7ffff000c4e8)
> >
> > at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jni.cpp:1383
> > #8  0x00007ffff6775573 in jni_NewObject (env=0x7ffff000c6f8,
> >     clazz=0x7ffff00ea088, methodID=0x7ffff010fee8)
> >
> > at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jni.cpp:1500
> > #9  0x00007ffff4e1103a in JNU_NewStringPlatform (env=0x7ffff000c6f8,
> >     str=0x7ffff0001ad8
> >
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre")
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/jdk/src/share/native/common/jni_util.c:741
> > #10 0x00007ffff4e10e8d in NewStringPlatform (env=0x7ffff000c6f8,
> >     str=0x7ffff0001ad8
> >
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre")
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/jdk/src/share/native/common/jni_util.c:711
> > #11 0x00007ffff6761ee5 in
> > java_lang_String::create_from_platform_dependent_str
> >     (
> >     str=0x7ffff0001ad8
> >
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre",
> __the_thread__=0x7ffff000c4e8)
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/classfile/javaClasses---Type
> <return> to continue, or q <return> to quit---
> > .cpp:245
> > #12 0x00007ffff67c8462 in set_property (props=...,
> >     key=0x7ffff0001728 "java.home",
> >     value=0x7ffff0001ad8
> >
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre",
> __the_thread__=0x7ffff000c4e8)
> >
> > at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jvm.cpp:319
> > #13 0x00007ffff67c8768 in JVM_InitProperties (env=0x7ffff000c6f8,
> >     properties=0x7ffff563c4e8)
> >
> > at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jvm.cpp:343
> > #14 0x00007ffff4e0846f in Java_java_lang_System_initProperties (
> >     env=0x7ffff000c6f8, cla=0x7ffff563c4d8, props=0x7ffff563c4e8)
> >
> > at
> /home/andyj/openjdk-8/jdk8-111/jdk/src/share/native/java/lang/System.c:379
> > #15 0x00007ffff5b8f0c7 in gload0L () at linkage.s:265
> > #16 0x00007fffe1081e7c in ?? ()
> > #17 0x0000000000000000 in ?? ()
> >
> >
> >
> >
> > On 11 February 2014 09:41, Edward Nevill <edward.nevill at linaro.org>
> > wrote:
> >         Hi Andy,
> >
> >
> >         On Tue, 2014-02-11 at 09:34 -0500, Andy Johnson wrote:
> >         > #0  0x0000007fa1098c78 in ?? ()
> >         > (gdb) where
> >         > #0  0x0000007fa1098c78 in ?? ()
> >         > #1  0x0000000000000034 in ?? ()
> >         > #2  0x0000000000000034 in ?? ()
> >         > Backtrace stopped: previous frame identical to this frame
> >         (corrupt stack?)
> >
> >
> >         Could you disassemble a few instructions around
> >         0x0000007fa1098c78 and let us know what you see.
> >
> >         Try say
> >
> >         x/20i $pc-40
> >
> >         Regards,
> >         Ed.
> >
> >
> >
> >
>
>
>


More information about the aarch64-port-dev mailing list