LLDB doesn't stop on SIGABRT (assert) with x86 executable on Apple ARM

Subprojects LLDB
1

I was trying to debug a x86_64 executable on my new Apple silicon and noticed it wouldn’t stop on asserts. See below 2 runs of a small Hello world compiled and run with arch x86 and then arm64. Is it an expected, known issue, if yes would you know of any workaround?

   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                               14:46:01
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (x86_64).
(lldb) r
Process 12031 launched: '/Users/flr03/Workspace/untitled' (x86_64)
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.

Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12031 exited with status = 6 (0x00000006) Terminated due to signal 6
(lldb) q
   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                        21s   14:46:31
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (arm64).
(lldb) r
Process 12077 launched: '/Users/flr03/Workspace/untitled' (arm64)
Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12077 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #4: 0x0000000100003154 untitled`main at main.cpp:10:5
   7   	{
   8   	    cout << "Hello World!" << endl;
   9
-> 10  	    assert(0);
   11
   12  	    return 0;
   13  	}
1 Like
2

If you watch the gdb-remote packet logs for the two sessions, you will see that in the Rosetta2 run, lldb is never told about the signal, the process just dies out from under us whereas in the AS native run, we get an EXC_SOFTWARE/EXC_SOFT_SIGNAL exception for the SIGABRT. This seems to be a problem with the Rosetta runtime. If you are interested in following up on this, please file a bug with Apple’s bug reporter (https://feedbackassistant.apple.com).

Jim

On Apr 4, 2023, at 7:02 AM, Florent R. via LLVM Discussion Forums notifications@llvm.discoursemail.com wrote:

GreatTux
April 4

I was trying to debug a x86_64 executable on my new Apple silicon and noticed it wouldn’t stop on asserts. See below 2 runs of a small Hello world compiled and run with arch x86 and then arm64. Is it an expected, known issue, if yes would you know of any workaround?

   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                               14:46:01
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (x86_64).
(lldb) r
Process 12031 launched: '/Users/flr03/Workspace/untitled' (x86_64)
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.

Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12031 exited with status = 6 (0x00000006) Terminated due to signal 6
(lldb) q
   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                        21s   14:46:31
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (arm64).
(lldb) r
Process 12077 launched: '/Users/flr03/Workspace/untitled' (arm64)
Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12077 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #4: 0x0000000100003154 untitled`main at main.cpp:10:5
   7   	{
   8   	    cout << "Hello World!" << endl;
   9
-> 10  	    assert(0);
   11
   12  	    return 0;
   13  	}

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

2 Likes
3

I’ve run into this as well and can reproduce with a simple c++ application. Has a bug report been created for this issue?

Temporary Workaround

Simply set a symbolic breakpoint on abort (or whatever).

Repro

Here’s some info to repro this issue.

❯ lldb --version
lldb-1300.0.42.3
Swift version 5.5.2-dev

Source code

#include <assert.h>

int main() {
    assert(0);
}

Usage

On x86 lldb doesn’t suspend execution:

❯ lldb main
(lldb) target create "main"
Current executable set to '[redacted]' (x86_64).
(lldb) r
Process 55575 launched: '[redacted]' (x86_64)
Assertion failed: (0), function main, file main.cpp, line 4.
Process 55575 exited with status = 6 (0x00000006) Terminated due to signal 6
(lldb)

On ARM it does:

❯ lldb main
(lldb) target create "main"
Current executable set to '[redacted]' (arm64).
(lldb) r
Process 55912 launched: '[redacted]' (arm64)
Assertion failed: (0), function main, file main.cpp, line 4.
Process 55912 stopped
* thread #1, stop reason = signal SIGABRT
    frame #0: 0x000000019f2a4724
->  0x19f2a4724: b.lo   0x19f2a4744
    0x19f2a4728: pacibsp 
    0x19f2a472c: stp    x29, x30, [sp, #-0x10]!
    0x19f2a4730: mov    x29, sp
Target 0: (main) stopped.
1 Like
4

There is an internal bug filed, though that doesn’t help you much externally. If you want to track the issue yourself, feel free to file a bug with Apple. It will get duped to the external one and then will allow you to hear back if/when the original is fixed.