[[!meta copyright="Copyright © 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]]."]]"""]] [[!tag open_issue_hurd]] # IRC, freenode, #hurd, 2013-02-09 also, can you actually gdb a process of another subhurd? yes but you need to talk to its proc server, don't you? i don't know but i did it several times how? the usual way gdb /path/to/bin pid but which pid? the hard part was finding the right pid well, gdb still needs to talk with the right proc too i don't think it does btw about the "unable to adjust libports thread priority" errors I'm seeing on the buildd consoles from what i've seen, proc "creates" tasks when it first sees them too it's about the destination port yes i have those when starting a subhurd too so it would mean that proc somehow got bogus ah so you can actually use your own proc yes and it feels bogus to me and I guess mach lets that proc access the task because your proc is privileged probably it feels bogus because, you can't rely on pids being allocated per task what i mean is that, if some tasks spawn and die quickly and you start another application running long enough to see it in ps it's pid will be +1, not +the number of created tasks which means the proc server will never have seen those previous tasks it's minor but a bit confusing i personally don't like seeing the tasks of other systems in ps :/ and despite the ability to use gdb from another hurd, i think we should improve the intra system debugging tools