0

I'm using asmjit to JIT compile a scripting language to X86-64 machine code. When I jump into my JIT compiled functions, they seem to work, but when they call one of my C++ functions, which in turn call printf (or cout), the program crashes. I can't figure out what's going on, or why it crashes.

Things look okay in LLDB. Does the LLDB output below mean that the memory reference -0x180(%rbp) is causing the crash? That doesn't look it should be a problem. The register values in rbp and rsp look sane.

Frame #4 is the JIT'd code, that's why it has no function name.

I'm new to debugging this kind of thing. If there is some info I should add to this question, please let me know.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00007ff8133bfebb libsystem_c.dylib`__vfprintf + 53
libsystem_c.dylib`:
->  0x7ff8133bfebb <+53>: movdqa %xmm0, -0x180(%rbp)
    0x7ff8133bfec3 <+61>: movq   0x10(%rcx), %rcx
    0x7ff8133bfec7 <+65>: movq   %rcx, -0x170(%rbp)
    0x7ff8133bfece <+72>: leaq   -0x288(%rbp), %rcx
Target 0: (myprog) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00007ff8133bfebb libsystem_c.dylib`__vfprintf + 53
    frame #1: 0x00007ff8133d1912 libsystem_c.dylib`vfprintf_l + 54
    frame #2: 0x00007ff8133edfd3 libsystem_c.dylib`printf + 174
    frame #3: 0x00000001000d6b8a myprog`myprog::print_i(x=123) at Core.cc:211:5
    frame #4: 0x00000001007a2030
    frame #5: 0x00000001000bf16b myprog`myprog::do_file_eval(mod=0x0000600001709000, stmtSeq=nullptr, showIR=false, log_asm=false) at Lang.cc:96:5
    frame #6: 0x0000000100080b5c myprog`run_file(path=0x00007ff7bfefef48, show_ir=false) at cmdline_main.cc:274:13
    frame #7: 0x00000001000845f9 myprog`main(argc=2, argv=0x00007ff7bfeff580) at cmdline_main.cc:403:9
    frame #8: 0x00007ff8131bd41f dyld`start + 1903
(lldb) register read
General Purpose Registers:
       rax = 0x0000000000000000
       rbx = 0x00007ff7bfefe908
       rcx = 0x00007ff7bfefe908
       rdx = 0x0000000100200474  "In print_i\n"
       rdi = 0x00007ff856bfaa18  __sF + 152
       rsi = 0x00007ff856bf9da0  __global_locale
       rbp = 0x00007ff7bfefe818
       rsp = 0x00007ff7bfefe488
        r8 = 0x0000000100200474  "In print_i\n"
        r9 = 0x00007ff7bfefe908
       r10 = 0x00007ff856bfac48  __sFX + 248
       r11 = 0x00007ff856bfac40  __sFX + 240
       r12 = 0x00007ff856bf9da0  __global_locale
       r13 = 0x00007ff7bfeff4d0
       r14 = 0x00007ff7bfefe908
       r15 = 0x0000000100200474  "In print_i\n"
       rip = 0x00007ff8133bfebb  libsystem_c.dylib`__vfprintf + 53
    rflags = 0x0000000000010246
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x0000000000000000

The print_i function, is simply:

void print_i(int64_t x) {
    printf("In print_i\n");
    printf("%lld\n", x);
}
Rob N
  • 15,024
  • 17
  • 92
  • 165
  • 1
    When a `movdqa` to a stack address faults in a compiler-generated function, almost always the cause is that a caller misaligned the stack, especially if the callstack involves functions not generated by a known-good compiler. The ABI requires `RSP % 16 == 0` before the `call`. – Peter Cordes Aug 12 '23 at 06:22
  • Thanks, that was my problem, and I was able to fix it with this information. – Rob N Aug 12 '23 at 17:43
  • BTW this is why AsmJit has function abstraction API. It's mostly used by it's Compiler tool, but also usable with Assembler/Builder. – Petr Aug 28 '23 at 15:03

0 Answers0