Issue #20249 has been updated by ko1 (Koichi Sasada). * As a MRI developer, I don't need loaded features (LF) and memory maps (MM) and it interrupts me to see the backtraces. In many cases they are not needed. * Because it is easy to repro, in many cases. * As a bug report receiver, it can be valuable in rare cases. * Checking LF to find suspicious libraries. * Checking SEGV memory area with MM. <- I observed only *one* time it is utilized. * I believe it is difficult to use `RUBY_FULL_CRASH_REPORT=1` for ordinal Ruby users because it is hard to reproduce the issue on production environment, and forget to set it. Ideas: 1. Remove long LF/MM because it is not used most of cases. * easiest and almost reasoanable. 2. Default on for ordinal Ruby users and provide a way to turn off LF/MM. * Environment variables on running time * configure options on build time 3. Generate a detailed error report with LF/MM in a file and show summary of errors on TTY. * it is similar to `RUBY_CRASH_REPORT` but generate reports without any configuration. * maybe the file path is issue. respect `TEMP` envvals? * it can cause disk full easily on development phase. For (3), the TTY lines should be: ``` t.rb:1: [BUG] Segmentation fault ruby 3.3.0dev (2023-09-15T04:27:19Z master fe0225ff4d) [x64-mswin64_140] -- Ruby level backtrace information ---------------------------------------- t.rb:1:in `<main>' t.rb:1:in `kill' -- C level backtrace information ------------------------------------------- C:\Windows\SYSTEM32\ntdll.dll(ZwWaitForSingleObject+0x14) [0x00007FFF625CF3F4] C:\Windows\System32\KERNELBASE.dll(WaitForSingleObjectEx+0x8e) [0x00007FFF5FC744EE] c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(rb_print_backtrace+0x34) [0x00007FFEF7D25D78] c:\ko1\ruby\src\wt_master\vm_dump.c:791 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(rb_vm_bugreport+0x1b7) [0x00007FFEF7D25F37] c:\ko1\ruby\src\wt_master\vm_dump.c:1091 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(rb_bug_for_fatal_signal+0x65) [0x00007FFEF7C532E9] c:\ko1\ruby\src\wt_master\error.c:819 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(sigsegv+0x3d) [0x00007FFEF7D4D58D] c:\ko1\ruby\src\wt_master\signal.c:920 C:\Windows\System32\ucrtbase.dll(raise+0x1e5) [0x00007FFF6015E5F5] c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(kill+0x49) [0x00007FFEF7CC0851] c:\ko1\ruby\src\wt_master\win32\win32.c:4993 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(rb_f_kill+0x200) [0x00007FFEF7D4CC6C] c:\ko1\ruby\src\wt_master\signal.c:494 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_call_cfunc_with_frame_+0x13e) [0x00007FFEF7C67E16] c:\ko1\ruby\src\wt_master\vm_insnhelper.c:3477 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEF7C67CD1] c:\ko1\ruby\src\wt_master\vm_insnhelper.c:3504 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_call_cfunc_other+0xb3) [0x00007FFEF7C67C93] c:\ko1\ruby\src\wt_master\vm_insnhelper.c:3531 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_call_cfunc+0x12c) [0x00007FFEF7C679B4] c:\ko1\ruby\src\wt_master\vm_insnhelper.c:3612 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_call_method_each_type+0x59c) [0x00007FFEF7C69108] c:\ko1\ruby\src\wt_master\vm_insnhelper.c:4389 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_call_method+0x14f) [0x00007FFEF7C68B3F] c:\ko1\ruby\src\wt_master\vm_insnhelper.c:4553 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_sendish+0x209) [0x00007FFEF7C72FA9] c:\ko1\ruby\src\wt_master\vm_insnhelper.c:5563 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(vm_exec_core+0x1c40) [0x00007FFEF7C6DAFC] c:\ko1\ruby\src\wt_master\vm_exec.c:101 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(rb_vm_exec+0x101) [0x00007FFEF7C62E0D] c:\ko1\ruby\src\wt_master\vm.c:2404 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(rb_ec_exec_node+0x135) [0x00007FFEF7C4C945] c:\ko1\ruby\src\wt_master\eval.c:291 c:\ko1\ruby\install\wt_master\bin\x64-vcruntime140-ruby330.dll(ruby_run_node+0x46) [0x00007FFEF7C4F112] c:\ko1\ruby\src\wt_master\eval.c:328 c:\ko1\ruby\install\wt_master\bin\ruby.exe(main+0x4a) [0x00007FF6BA62104A] c:\ko1\ruby\src\wt_master\main.c:59 c:\ko1\ruby\install\wt_master\bin\ruby.exe(__scrt_common_main_seh+0x10c) [0x00007FF6BA621264] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 C:\Windows\System32\KERNEL32.DLL(BaseThreadInitThunk+0x1d) [0x00007FFF60DE257D] Details: /tmp/ruby-crash-log-1234 ``` In details, we can put additional information, for example backtraces in all threads. BTW `RUBY_FULL_CRASH_REPORT=1` can be useful on Ruby's CI environment. ---------------------------------------- Feature #20249: Introduce a backtrace-only mode for rb_bug() https://bugs.ruby-lang.org/issues/20249#change-106727 * Author: osyoyu (Daisuke Aritomo) * Status: Open * Priority: Normal ---------------------------------------- ## Background When a segfault or some unexpected situation occurs, `rb_bug()` is called and prints some few hundred to thousands of lines. The most helpful parts are (arguably) "Ruby level backtrace information" and "C-level backtrace information", but those parts are buried in the very lengthy report. In particular, the "Other runtime information" which contains the list of loaded features (scripts?) and the process memory map could be extremely long despite it does not come very useful, at least when developing C extensions. Even a minimal report from a simple script would consist of 250 lines and require 7 PgUps on my MacBook Air (13 inch) to reach the backtrace part, which contains all the information I need. ## Proposal My proposal is to default to a "minimal report" mode with a limited set of sections, perhaps only "Ruby level backtrace information" and "C level backtrace information" only When a full report is desired (i.e. for bug reports), the user could re-run the script with an special environment variable, such as `RUBY_FULL_CRASH_REPORT=1`. Rust implmements a similar pattern. It doesn't print the full backtrace on panics by default; instead, it guides the user to re-run the program with `RUST_BACKTRACE=1`. It might be hard to reproduce some crashes and segfaults, especially in long-running daemons. It might be nice to default to the "full" mode when stdout is not a tty, since daemons tend to run in non-tty environments. ## Appendix A typical crash report would look like this: ``` ../../example.rb: [BUG] ruby 3.4.0dev (2024-01-20T15:27:19Z master 366b14c0cd) [arm64-darwin23] -- Crash Report log information -------------------------------------------- (5 lines) -- Control frame information ----------------------------------------------- (~50 lines) -- Ruby level backtrace information ---------------------------------------- (depends on program; typically ~50 lines in Rails) -- C level backtrace information ------------------------------------------- (50+-ish lines, depends on program) -- Machine register context ------------------------------------------------ (~10 lines) -- Threading information --------------------------------------------------- (2 lines) -- Other runtime information ----------------------------------------------- * Loaded script (1 line) * Loaded features (depends on program; 800+ lines in Rails) * Process memory map (depends on environment; around 200 lines?) -- https://bugs.ruby-lang.org/