Bug #18735: The crash reporter need to be updated for Apple silicon

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN

[byroot (Jean Boussier)]

C backtrace dumping is only enabled for x86_64 arch on macOS: if defined(__APPLE__) && defined(__x86_64__) && defined(HAVE_LIBUNWIND_H)

I tested libunwind on M1 Mac, it seems to work fine. I think we should either remove this x86_64 condition, or add an arm64 condition as well.

Proposed patch: https://github.com/ruby/ruby/pull/5770

The register dumping code would need to be implemented as well, but it's a bit beyond my capacities.

I also think we should backport the fix on older rubies so that in case of crash we get better crash reports.

[mame (Yusuke Endoh)]

I think your patch does not work well for me. Does it work well on your machine?

% sw_vers
ProductName:    macOS
ProductVersion: 11.6
BuildVersion:   20G165

% ./miniruby -e 'Process.kill "SEGV", $$'
-e:1: [BUG] Segmentation fault at 0x0000000102312568
ruby 3.2.0dev (2022-04-15T08:52:10Z master 7f81f33547) [arm64-darwin20]

*snip*

-- C level backtrace information -------------------------------------------
/Users/mame/work/ruby/./miniruby(rb_vm_bugreport+0x285e000000000960) [0x285e00010248299c]
/Users/mame/work/ruby/./miniruby(0x4d788001022bfcb8) [0x4d788001022bfcb8]
/Users/mame/work/ruby/./miniruby(0x42508001023e6e14) [0x42508001023e6e14]
/usr/lib/system/libsystem_platform.dylib(_sigtramp+0x2d78800000000038) [0x2d788001868dac44]
[0x38]

-- Other runtime information -----------------------------------------------

*snip*

The trace has no information of any meaningful call frames. It should include rb_f_kill, vm_exec_core, etc. In fact it does on Linux as follows.

$ ./miniruby -e 'Process.kill "SEGV", $$'
-e:1: [BUG] Segmentation fault at 0x000003e800093ad5
ruby 3.2.0dev (2022-04-04T07:06:16Z master 57377e5d53) [x86_64-linux]

*snip*

-- C level backtrace information -------------------------------------------
./miniruby(rb_vm_bugreport+0x5bb) [0x55f6825c129b]
./miniruby(rb_bug_for_fatal_signal+0xec) [0x55f6823a5f6c]
./miniruby(sigsegv+0x4d) [0x55f68250fc2d]
[0x7f2f7365b520]
[0x7f2f7365b75b]
./miniruby(rb_f_kill+0x239) [0x55f682510dd9]
./miniruby(vm_call_cfunc_with_frame+0x137) [0x55f6825a1207]
./miniruby(vm_exec_core+0x114) [0x55f6825b2954]
./miniruby(rb_vm_exec+0xd3) [0x55f6825a3b83]
./miniruby(rb_ec_exec_node+0xb1) [0x55f6823aaca1]
./miniruby(ruby_run_node+0x4d) [0x55f6823b014d]
./miniruby(rb_main+0x73) [0x55f682302c73]
[0x7f2f73642fd0]
[0x7f2f7364307d]
./miniruby(_start+0x25) [0x55f682302b25]

*snip*

[mame (Yusuke Endoh)]

I guess this commit of libunwind is required to work on M1 mac. Looks like the commit is not released yet.

I couldn't build the master version of libunwind because I have no privilege to install some dependencies. Can you confirm that your PR works well with the latest libunwind? I think it is okay to merge it if it works well.

[byroot (Jean Boussier)]

No you're right, my patch isn't working as well as I though it was.

Can you confirm that your PR works well with the latest libunwind?

I'm having trouble compiling it unfortunately. I'll try more later.

But I suppose we can assume Apple is going to ship a working libunwind at some point right?

[mame (Yusuke Endoh)]

byroot (Jean Boussier) wrote in #note-3:

But I suppose we can assume Apple is going to ship a working libunwind at some point right?

Agreed, I'm not strongly against. But I just think it's better to make sure it works if libunwind is appropriately installed.

[mame (Yusuke Endoh)]

• Status changed from Open to Closed

Merged by @naruse (Yui NARUSE) at fa2df520bcaaf3957db0489f1237311f091ac08d