[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!meta title="GDB: attach"]] [[!tag open_issue_gdb]] # [[gdb_thread_ids]] # IRC, freenode, #hurd, 2012-06-30 hm, gdb isn't able to determine which thread is running when attaching to a process # IRC, freenode, #hurd, 2012-07-02 woah, now that's a weird message ! when using gdb on a hanged ext2fs : Pid 938 has an additional task suspend count of 1; clear it? (y or n) when hanged, gdb thinks the target task is already being debugged :/ no wonder why it's completely stuck hm, the task_suspend might actually be the crash-dump-core server attempting to create the core :/ hm interesting, looks like a problem with the diskfs_catch_exception macro braunr: what's up with it? pinotree: it uses setjmp hm random corruptions :/ definitely looks like a concurrency problem # IRC, freenode, #hurd, 2012-05-23 /build/buildd-gdb_7.4really-1-hurd-i386-UKStgK/gdb-7.4really/gdb/thread.c:72: internal-error: inferior_thread: Assertion `tp' failed. arg pinotree: Been doing anything "special"? Is it reproducible? trying to debug something Indeed. ;-) i'm not sure i'm doing anything special, just trying to attach a process That is supposed to work. If the permission match. # `gdb --pid [PID]` That is, not explicitly specifying an `executable-file`. ## IRC, OFTC, debian-hurd, 2013-04-15 I don't seem to be able to run gdb that happened on the buildd and happens on exodar too #0 0x010c07cc in ?? () #1 0x010c1078 in ?? () #2 0x0109eabf in ?? () [...] Backtrace stopped: previous frame inner to this frame (corrupt stack?) that's pid 24235 on exodar I did gdb -p 24235 and then bt just the output above I don't know about gdb -p I usually run gdb /home/paravoid/gdnsd-1.8.1/plugins/meta/libgdmaps/t/.libs/lt-t17_extn_empty.bin 24235 okay, that indeed works I guess the support for finding out the binary automatically wasn't done yet on hurd