* Re: [PATCH v2 00/36] Guile extension language for GDB @ 2014-04-20 16:58 Tillmann Karras 2014-04-27 22:15 ` Doug Evans 0 siblings, 1 reply; 9+ messages in thread From: Tillmann Karras @ 2014-04-20 16:58 UTC (permalink / raw) To: gdb-patches Hi. This commit series (ed3ef33944c39d9a3cea72b9a7cef3c20f0e3461) breaks "gdb -ex r gdb" for me. The child gdb seems to hang without getting to the prompt. It works when compiling current master (8b5c7890e8bfa3360339c303599fe5b0c9faa848) with --with-guile=no. I'm on Arch Linux testing x86_64 using the gdb-git AUR package with options=(!libtool debug !strip). Cheers, Tillmann ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 00/36] Guile extension language for GDB 2014-04-20 16:58 [PATCH v2 00/36] Guile extension language for GDB Tillmann Karras @ 2014-04-27 22:15 ` Doug Evans 2014-05-04 19:59 ` Tillmann Karras 0 siblings, 1 reply; 9+ messages in thread From: Doug Evans @ 2014-04-27 22:15 UTC (permalink / raw) To: Tillmann Karras; +Cc: gdb-patches On Sun, Apr 20, 2014 at 9:58 AM, Tillmann Karras <tillmann@selfnet.de> wrote: > Hi. > > This commit series (ed3ef33944c39d9a3cea72b9a7cef3c20f0e3461) breaks "gdb > -ex r gdb" for me. The child gdb seems to hang without getting to the > prompt. It works when compiling current master > (8b5c7890e8bfa3360339c303599fe5b0c9faa848) with --with-guile=no. > > I'm on Arch Linux testing x86_64 using the gdb-git AUR package with > options=(!libtool debug !strip). Hi. I went to the trouble of installing arch-linux in a vmplayer vm, and trying to repro this. I can't. If you're running gdb under gdb, and the child gdb is hanging, can you type Ctrl-C when it hangs, and then obtain a backtrace of the child gdb? It's been suggested to give the following a try. Does that fix things for you? bash$ export GC_MARKERS=1 before starting gdb It's a workaround for a libgc 7.4.0 bug. I verified my arch-linux has libgc 7.4.0, but I may have just gotten lucky. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 00/36] Guile extension language for GDB 2014-04-27 22:15 ` Doug Evans @ 2014-05-04 19:59 ` Tillmann Karras 2014-05-05 6:03 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Tillmann Karras @ 2014-05-04 19:59 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches On 2014-04-28 00:15, Doug Evans wrote: > If you're running gdb under gdb, and the child gdb is hanging, > can you type Ctrl-C when it hangs, and then obtain a backtrace of the > child gdb? Pressing Ctrl-C just prints "[New Thread 0x7ffff4b6f700 (LWP 14601)]" but I don't get any prompt. > It's been suggested to give the following a try. > Does that fix things for you? > > bash$ export GC_MARKERS=1 > > before starting gdb > It's a workaround for a libgc 7.4.0 bug. > I verified my arch-linux has libgc 7.4.0, but I may have just gotten > lucky. Yes, "gdb -ex 'set environment GC_MARKERS 1' -ex r gdb" makes it work for me. (Maybe your test VM had only one core?) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 00/36] Guile extension language for GDB 2014-05-04 19:59 ` Tillmann Karras @ 2014-05-05 6:03 ` Eli Zaretskii 2014-05-12 3:25 ` Doug Evans 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2014-05-05 6:03 UTC (permalink / raw) To: Tillmann Karras; +Cc: xdje42, gdb-patches > Date: Sun, 04 May 2014 21:59:08 +0200 > From: Tillmann Karras <tillmann@selfnet.de> > Cc: gdb-patches@sourceware.org > > On 2014-04-28 00:15, Doug Evans wrote: > > If you're running gdb under gdb, and the child gdb is hanging, > > can you type Ctrl-C when it hangs, and then obtain a backtrace of the > > child gdb? > > Pressing Ctrl-C just prints "[New Thread 0x7ffff4b6f700 (LWP 14601)]" > but I don't get any prompt. My crystal ball says that Ctrl-C causes Guile to start its signal delivery thread, which is the reason for the "New Thread" message you see. > > It's been suggested to give the following a try. > > Does that fix things for you? > > > > bash$ export GC_MARKERS=1 > > > > before starting gdb > > It's a workaround for a libgc 7.4.0 bug. > > I verified my arch-linux has libgc 7.4.0, but I may have just gotten > > lucky. > > Yes, "gdb -ex 'set environment GC_MARKERS 1' -ex r gdb" makes it work > for me. (Maybe your test VM had only one core?) What bug is that in libgc, and what are its symptoms? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 00/36] Guile extension language for GDB 2014-05-05 6:03 ` Eli Zaretskii @ 2014-05-12 3:25 ` Doug Evans 2014-05-12 8:00 ` GDB-Guile vs. libgc 7.4 marker threads Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Doug Evans @ 2014-05-12 3:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tillmann Karras, gdb-patches, Ludovic Courtès [+ ludovic] On Sun, May 4, 2014 at 11:03 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Sun, 04 May 2014 21:59:08 +0200 >> From: Tillmann Karras <tillmann@selfnet.de> >> Cc: gdb-patches@sourceware.org >> >> On 2014-04-28 00:15, Doug Evans wrote: >> > If you're running gdb under gdb, and the child gdb is hanging, >> > can you type Ctrl-C when it hangs, and then obtain a backtrace of the >> > child gdb? >> >> Pressing Ctrl-C just prints "[New Thread 0x7ffff4b6f700 (LWP 14601)]" >> but I don't get any prompt. > > My crystal ball says that Ctrl-C causes Guile to start its signal > delivery thread, which is the reason for the "New Thread" message you > see. > >> > It's been suggested to give the following a try. >> > Does that fix things for you? >> > >> > bash$ export GC_MARKERS=1 >> > >> > before starting gdb >> > It's a workaround for a libgc 7.4.0 bug. >> > I verified my arch-linux has libgc 7.4.0, but I may have just gotten >> > lucky. >> >> Yes, "gdb -ex 'set environment GC_MARKERS 1' -ex r gdb" makes it work >> for me. (Maybe your test VM had only one core?) > > What bug is that in libgc, and what are its symptoms? A google search for libgc 7.4 GC_MARKERS found this: https://lists.gnu.org/archive/html/guile-commits/2014-04/msg00051.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* GDB-Guile vs. libgc 7.4 marker threads 2014-05-12 3:25 ` Doug Evans @ 2014-05-12 8:00 ` Ludovic Courtès 2014-05-12 13:39 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2014-05-12 8:00 UTC (permalink / raw) To: Doug Evans; +Cc: Eli Zaretskii, Tillmann Karras, gdb-patches, Andy Wingo [+ Andy :-)] Doug Evans <xdje42@gmail.com> skribis: > On Sun, May 4, 2014 at 11:03 PM, Eli Zaretskii <eliz@gnu.org> wrote: >>> Date: Sun, 04 May 2014 21:59:08 +0200 >>> From: Tillmann Karras <tillmann@selfnet.de> >>> Cc: gdb-patches@sourceware.org >>> >>> On 2014-04-28 00:15, Doug Evans wrote: >>> > If you're running gdb under gdb, and the child gdb is hanging, >>> > can you type Ctrl-C when it hangs, and then obtain a backtrace of the >>> > child gdb? >>> >>> Pressing Ctrl-C just prints "[New Thread 0x7ffff4b6f700 (LWP 14601)]" >>> but I don't get any prompt. >> >> My crystal ball says that Ctrl-C causes Guile to start its signal >> delivery thread, which is the reason for the "New Thread" message you >> see. >> >>> > It's been suggested to give the following a try. >>> > Does that fix things for you? >>> > >>> > bash$ export GC_MARKERS=1 >>> > >>> > before starting gdb >>> > It's a workaround for a libgc 7.4.0 bug. >>> > I verified my arch-linux has libgc 7.4.0, but I may have just gotten >>> > lucky. >>> >>> Yes, "gdb -ex 'set environment GC_MARKERS 1' -ex r gdb" makes it work >>> for me. (Maybe your test VM had only one core?) >> >> What bug is that in libgc, and what are its symptoms? > > A google search for libgc 7.4 GC_MARKERS found this: > > https://lists.gnu.org/archive/html/guile-commits/2014-04/msg00051.html Yes, but note that this commit is for Guile 2.2. That said, although Guile 2.0 builds and runs fine with 7.4, I noticed that GDB-Guile is confused when there are several marker threads. Thus, we have to set GC_MARKERS=1 when running Guile-GDB with Guile 2.0 on libgc 7.4. Probably the GC_MARKERS hack linked above should be applied to GDB as well. WDYT? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB-Guile vs. libgc 7.4 marker threads 2014-05-12 8:00 ` GDB-Guile vs. libgc 7.4 marker threads Ludovic Courtès @ 2014-05-12 13:39 ` Eli Zaretskii 2014-05-13 15:53 ` Ludovic Courtès 2014-05-15 7:46 ` Andy Wingo 0 siblings, 2 replies; 9+ messages in thread From: Eli Zaretskii @ 2014-05-12 13:39 UTC (permalink / raw) To: Ludovic Courtès; +Cc: xdje42, tillmann, gdb-patches, wingo > From: ludo@gnu.org (Ludovic Courtès) > Cc: Eli Zaretskii <eliz@gnu.org>, Tillmann Karras <tillmann@selfnet.de>, "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>, Andy Wingo <wingo@pobox.com> > Date: Mon, 12 May 2014 10:00:22 +0200 > > > https://lists.gnu.org/archive/html/guile-commits/2014-04/msg00051.html > > Yes, but note that this commit is for Guile 2.2. > > That said, although Guile 2.0 builds and runs fine with 7.4 Are you saying that Guile 2.0.x does not suffer from the bug in libgc-7.4.0? > I noticed that GDB-Guile is confused when there are several marker > threads. Thus, we have to set GC_MARKERS=1 when running Guile-GDB > with Guile 2.0 on libgc 7.4. Are you sure this confusion is related to the same libgc issue? Should we talk to libgc developers about that? > Probably the GC_MARKERS hack linked above should be applied to GDB as > well. WDYT? If we are sure this solves the problem, IMO yes. But it would be nice to try to have a new libgc release that is free from this problem, if possible. Also, maybe we should document in the same comment what, if anything, does this restriction mean for GDB-Guile users. Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB-Guile vs. libgc 7.4 marker threads 2014-05-12 13:39 ` Eli Zaretskii @ 2014-05-13 15:53 ` Ludovic Courtès 2014-05-15 7:46 ` Andy Wingo 1 sibling, 0 replies; 9+ messages in thread From: Ludovic Courtès @ 2014-05-13 15:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: xdje42, tillmann, gdb-patches, wingo Eli Zaretskii <eliz@gnu.org> skribis: >> From: ludo@gnu.org (Ludovic Courtès) >> Cc: Eli Zaretskii <eliz@gnu.org>, Tillmann Karras <tillmann@selfnet.de>, "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>, Andy Wingo <wingo@pobox.com> >> Date: Mon, 12 May 2014 10:00:22 +0200 >> >> > https://lists.gnu.org/archive/html/guile-commits/2014-04/msg00051.html >> >> Yes, but note that this commit is for Guile 2.2. >> >> That said, although Guile 2.0 builds and runs fine with 7.4 > > Are you saying that Guile 2.0.x does not suffer from the bug in > libgc-7.4.0? Yes, in my experience. >> I noticed that GDB-Guile is confused when there are several marker >> threads. Thus, we have to set GC_MARKERS=1 when running Guile-GDB >> with Guile 2.0 on libgc 7.4. > > Are you sure this confusion is related to the same libgc issue? What I know is that setting GC_MARKERS=1 allows GDB-Guile with libgc 7.4.0 to work flawlessly, whereas it otherwise hangs when not doing that. For instance, with GC_MARKERS unset (my machine has 4 cores, so libgc spawns 3 marker threads), I can run: --8<---------------cut here---------------start------------->8--- $ ./gdb --args guile GNU gdb (GDB) 7.7.50.20140505-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from guile...done. (gdb) r Starting program: /home/ludo/soft/bin/guile warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/libthread_db.so.1". --8<---------------cut here---------------end--------------->8--- and it hangs right here. The backtrace of gdb at this point is: --8<---------------cut here---------------start------------->8--- (gdb) bt #0 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31 #1 __GI___sigsuspend (set=set@entry=0xb702c0 <suspend_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #2 0x0000000000451ced in linux_nat_wait_1 (ops=<optimized out>, target_options=0, ourstatus=0x7fffee48a910, ptid=...) at linux-nat.c:3418 #3 linux_nat_wait (ops=<optimized out>, ptid=..., ourstatus=0x7fffee48a910, target_options=0) at linux-nat.c:3654 #4 0x0000000000458d66 in thread_db_wait (ops=<optimized out>, ptid=..., ourstatus=0x7fffee48a910, options=0) at linux-thread-db.c:1486 #5 0x000000000056f59d in delegate_wait (self=<optimized out>, arg1=..., arg2=<optimized out>, arg3=<optimized out>) at target-delegates.c:60 #6 0x0000000000576d33 in target_wait (ptid=..., status=status@entry=0x7fffee48a910, options=options@entry=0) at target.c:2103 #7 0x0000000000540f95 in wait_for_inferior () at infrun.c:2810 #8 0x00000000005411ef in proceed (addr=<optimized out>, siggnal=siggnal@entry=GDB_SIGNAL_0, step=step@entry=0) at infrun.c:2371 #9 0x00000000005367dd in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=<optimized out>) at infcmd.c:631 #10 0x000000000060a08b in execute_command (p=<optimized out>, p@entry=0x224e6c0 "", from_tty=1) at top.c:460 #11 0x00000000005567d5 in command_handler (command=0x224e6c0 "") at event-top.c:437 #12 0x0000000000556db4 in command_line_handler (rl=<optimized out>) at event-top.c:634 #13 0x0000000000650ac0 in rl_callback_read_char () at callback.c:220 #14 0x0000000000556839 in rl_callback_read_char_wrapper (client_data=<optimized out>) at event-top.c:166 #15 0x0000000000555441 in process_event () at event-loop.c:342 #16 0x000000000055580a in gdb_do_one_event () at event-loop.c:394 #17 0x0000000000555a5e in start_event_loop () at event-loop.c:431 #18 0x000000000054f453 in captured_command_loop (data=data@entry=0x0) at main.c:266 #19 0x000000000054caca in catch_errors (func=func@entry=0x54f440 <captured_command_loop>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x712212 "", mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:524 #20 0x00000000005501b6 in captured_main (data=data@entry=0x7fffee48adb0) at main.c:1054 #21 0x000000000054caca in catch_errors (func=func@entry=0x54f740 <captured_main>, func_args=func_args@entry=0x7fffee48adb0, errstring=errstring@entry=0x712212 "", mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:524 #22 0x000000000055067b in gdb_main (args=args@entry=0x7fffee48adb0) at main.c:1062 #23 0x000000000040b645 in main (argc=<optimized out>, argv=<optimized out>) at gdb.c:33 (gdb) info threads Id Target Id Frame 4 Thread 0x7f0e56efb700 (LWP 17172) "gdb" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 3 Thread 0x7f0e566aa700 (LWP 17173) "gdb" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 2 Thread 0x7f0e55e59700 (LWP 17174) "gdb" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 * 1 Thread 0x7f0e5fb93740 (LWP 17170) "gdb" 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31 (gdb) thread 2 [Switching to thread 2 (Thread 0x7f0e55e59700 (LWP 17174))] #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 185 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory. (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f0e5ea28907 in GC_wait_marker () at pthread_support.c:2036 #2 0x00007f0e5ea1f31a in GC_help_marker (my_mark_no=my_mark_no@entry=11) at mark.c:1160 #3 0x00007f0e5ea26f5c in GC_mark_thread (id=<optimized out>) at pthread_support.c:389 #4 0x00007f0e5e010052 in start_thread (arg=0x7f0e55e59700) at pthread_create.c:309 #5 0x00007f0e5e521e1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) thread 1 [Switching to thread 1 (Thread 0x7f0e5fb93740 (LWP 17170))] #0 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31 31 ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory. (gdb) finish Run till exit from #0 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31 --8<---------------cut here---------------end--------------->8--- and ‘sigsuspend’ never returns. So it looks like it’s losing some SIGCHLDs, which would be unrelated to the problem we’re seeing with Guile 2.2. libgc installs handlers for SIGPWR and SIGXCPU, which it uses to coordinate stop-the-world GCs, but that doesn’t interfere AFAICS (and it’s the case regardless of whether there are 1 or more marker threads.) I’ve investigated a bit but can’t find any why/how libgc could interfere with gdb’s signal handling. Ideas? Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB-Guile vs. libgc 7.4 marker threads 2014-05-12 13:39 ` Eli Zaretskii 2014-05-13 15:53 ` Ludovic Courtès @ 2014-05-15 7:46 ` Andy Wingo 1 sibling, 0 replies; 9+ messages in thread From: Andy Wingo @ 2014-05-15 7:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Ludovic Courtès, xdje42, tillmann, gdb-patches On Mon 12 May 2014 15:39, Eli Zaretskii <eliz@gnu.org> writes: >> > https://lists.gnu.org/archive/html/guile-commits/2014-04/msg00051.html >> Probably the GC_MARKERS hack linked above should be applied to GDB as >> well. WDYT? > > If we are sure this solves the problem, IMO yes. But it would be nice > to try to have a new libgc release that is free from this problem, if > possible. Also, maybe we should document in the same comment what, if > anything, does this restriction mean for GDB-Guile users. I have asked for a new libgc release, but I have not gotten a response. I will ask again. Setting GC_MARKERS=1 is not visible to the user. There is no change in functionality. Using multiple mark threads is purely an optimization. So I don't think it needs to be documented. Regards, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-05-15 7:46 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-20 16:58 [PATCH v2 00/36] Guile extension language for GDB Tillmann Karras 2014-04-27 22:15 ` Doug Evans 2014-05-04 19:59 ` Tillmann Karras 2014-05-05 6:03 ` Eli Zaretskii 2014-05-12 3:25 ` Doug Evans 2014-05-12 8:00 ` GDB-Guile vs. libgc 7.4 marker threads Ludovic Courtès 2014-05-12 13:39 ` Eli Zaretskii 2014-05-13 15:53 ` Ludovic Courtès 2014-05-15 7:46 ` Andy Wingo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox