Bug#1016630: guile-3.0: gdb guile results in SIGSEGV before guile even starts!
Linas Vepstas writes: > Wow! Well, I feel kind of dumb to not actually have tried that; I have been > trained that SIGSEGV is a full stop, and it's pointless to try to > continue. Thank you! Of course, and I might well not have assumed otherwise either -- but yeah, I have the impression that libgc does some "interesting" things. > I can't imagine I will be the first and only one to be surprised by this > change of behavior, but I can't think of a good solution to propose, just > right now. Agreed, I suppose we could consider adding it to a README.Debian, but not sure people (including me) would notice it in the relvant circumstances. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1016630: guile-3.0: gdb guile results in SIGSEGV before guile even starts!
> ``` > > $ gdb guile > > GNU gdb (Debian 12.1-3) 12.1 > > ... etc ... > > Reading symbols from guile... > > (No debugging symbols found in guile) > > (gdb) r > > Starting program: /usr/bin/guile > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > > > Program received signal SIGSEGV, Segmentation fault. > > According (and thanks) to mwette, this is actually expected behavior: > https://hboehm.info/gc/debugging.html > > And just continuing via "c" should work. > Wow! Well, I feel kind of dumb to not actually have tried that; I have been trained that SIGSEGV is a full stop, and it's pointless to try to continue. Thank you! I can't imagine I will be the first and only one to be surprised by this change of behavior, but I can't think of a good solution to propose, just right now. -- Lnas
Bug#1016630: guile-3.0: gdb guile results in SIGSEGV before guile even starts!
Linas Vepstas writes: > Package: guile-3.0 > Version: 3.0.8-2 > Severity: normal > X-Debbugs-Cc: linasveps...@gmail.com > > Dear Maintainer, > > To debug large complex programs that use guile extensions, I run `gdb > guile` regularly. This does not work w/ current version in testing. I > get this: > ``` > $ gdb guile > GNU gdb (Debian 12.1-3) 12.1 > ... etc ... > Reading symbols from guile... > (No debugging symbols found in guile) > (gdb) r > Starting program: /usr/bin/guile > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. According (and thanks) to mwette, this is actually expected behavior: https://hboehm.info/gc/debugging.html And just continuing via "c" should work. It looks like guile's source tree gdbinit has the handlers for SIGPWR and SIGXCPU, but not SIGBUS or SIGSEGV. Hope this helps (I've marked this bug as done, but please feel free to re-open it if that doesn't sound reasonable to you yet.) -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1016630: guile-3.0: gdb guile results in SIGSEGV before guile even starts!
Package: guile-3.0 Version: 3.0.8-2 Severity: normal X-Debbugs-Cc: linasveps...@gmail.com Dear Maintainer, To debug large complex programs that use guile extensions, I run `gdb guile` regularly. This does not work w/ current version in testing. I get this: ``` $ gdb guile GNU gdb (Debian 12.1-3) 12.1 ... etc ... Reading symbols from guile... (No debugging symbols found in guile) (gdb) r Starting program: /usr/bin/guile [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77c3707a in GC_find_limit_with_bound () from /lib/x86_64-linux-gnu/libgc.so.1 (gdb) bt #0 0x77c3707a in GC_find_limit_with_bound () from /lib/x86_64-linux-gnu/libgc.so.1 #1 0x77c37162 in GC_init_linux_data_start () from /lib/x86_64-linux-gnu/libgc.so.1 #2 0x77c355df in GC_init () from /lib/x86_64-linux-gnu/libgc.so.1 #3 0x77ec522a in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1 #4 0x77f287af in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1 #5 0x77f28b66 in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1 #6 0x77c350e7 in GC_call_with_stack_base () from /lib/x86_64-linux-gnu/libgc.so.1 #7 0x77f23e68 in scm_with_guile () from /lib/x86_64-linux-gnu/libguile-3.0.so.1 #8 0x77ec5185 in scm_boot_guile () from /lib/x86_64-linux-gnu/libguile-3.0.so.1 #9 0x510f in ?? () #10 0x77cb181d in __libc_start_main (main=0x50b0, argc=1, argv=0x7fffe198, init=, fini=, rtld_fini=, stack_end=0x7fffe188) at ../csu/libc-start.c:332 #11 0x51aa in ?? () ``` Looking at the above stack trace, I suspect the issue is actually with bdwgc ... unless guile is doing something wacky with stacks before initing bdwgc. I guess this could also be a gdb bug!?? Of course, guile itself works just fine -- it only crashes when starting guile from gdb! So that is ... confusingly bizarre. For me personally, tis is a critical bug; I depend strongly on having gdb working correctly. -- linas -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.15 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages guile-3.0 depends on: ii guile-3.0-libs 3.0.8-2 guile-3.0 recommends no packages. Versions of packages guile-3.0 suggests: pn guile-3.0-doc -- no debconf information
