[#109095] [Ruby master Misc#18888] Migrate ruby-lang.org mail services to Google Domains and Google Workspace — "shugo (Shugo Maeda)" <noreply@...>
Issue #18888 has been reported by shugo (Shugo Maeda).
16 messages
2022/06/30
[ruby-core:108819] [Ruby master Bug#17656] Improper functions shown in C level backtrace information
From:
"mame (Yusuke Endoh)" <noreply@...>
Date:
2022-06-09 08:40:19 UTC
List:
ruby-core #108819
Issue #17656 has been updated by mame (Yusuke Endoh). I could reproduce it with clang 12. Could you explaiun the rationale of `traces[i] = (void *)(((uintptr_t)traces[i] & (~1)) - 1);`? [The message you referred](http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2020-July/004694.html) says "subtracting 1 from the return address, although not guaranteed to provide the exact calling address, generally will produce an address within the same context as the calling address, and that usually is sufficient." but I have no idea why `& (~1)` is needed. Is this a common knowledge about 32-bit arm? ---------------------------------------- Bug #17656: Improper functions shown in C level backtrace information https://bugs.ruby-lang.org/issues/17656#change-97896 * Author: xtkoba (Tee KOBAYASHI) * Status: Feedback * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The following is an example of C backtrace output on aarch64-linux, where `sig_do_nothing` is shown in spite of segfault: ``` -- C level backtrace information ------------------------------------------- /var/tmp/build.debug/aarch64.clang.O0/lib/libruby.so.3.0(rb_print_backtrace+0x24) [0x5500b86c74] vm_dump.c:758 /var/tmp/build.debug/aarch64.clang.O0/lib/libruby.so.3.0(rb_vm_bugreport+0xa8) [0x5500b86d38] vm_dump.c:999 /var/tmp/build.debug/aarch64.clang.O0/lib/libruby.so.3.0(rb_bug_for_fatal_signal+0x108) [0x550092fb7c] error.c:786 /var/tmp/build.debug/aarch64.clang.O0/lib/libruby.so.3.0(sig_do_nothing+0x0) [0x5500abfa90] signal.c:960 /var/tmp/build.debug/aarch64.clang.O0/lib/libruby.so.3.0(sigsegv) (null):0 [0x50c810] (...) ``` This happens because `backtrace(3)` fills the buffer with the return addresses retrieved from stack frames. A workaround is to subtract 1 from each return address [1], as in the attached patch. [1] http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2020-July/004694.html ---Files-------------------------------- ruby-backtrace-address-off-by-1.patch (470 Bytes) -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>