Bug #18735
closed
The crash reporter need to be updated for Apple silicon
Description
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.
Updated by mame (Yusuke Endoh) about 2 years ago
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*
Updated by mame (Yusuke Endoh) about 2 years ago
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.
Updated by byroot (Jean Boussier) about 2 years ago
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?
Updated by mame (Yusuke Endoh) about 2 years ago
byroot (Jean Boussier) wrote in #note-3:
But I suppose we can assume Apple is going to ship a working
libunwindat 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.
Updated by mame (Yusuke Endoh) about 2 years ago
- Status changed from Open to Closed