[[!meta copyright="Copyright © 2007, 2008, 2010, 2013, 2014 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]]."]]"""]] # Strategies * [[GDB]] -- the GNU debugger * [[gdb/Backtrace]]s * [[subhurd]] -- running another Hurd system in parallel * In context of [[glibc/debugging/ld_so_console]]: [[!message-id "20111108190129.750BC2C098@topped-with-meat.com"]] * [[rpctrace]] -- tracing [[RPC]]s * [[microkernel/mach/gnumach/interface/syscall/mach_print]] sycall # About Specific Packages * [[glibc]] * [[translator]]s * [[trap_in_the_kernel]] * [[hardware_watchpoint]] # IRC, freenode, #hurd, 2013-06-30 braunr: I don't understand your question totally, but I want to know how do you do this inspecting? i have a small test program that creates a thread, and inspect its state before any thread dies i use portinfo and rpctrace (there is also vminfo but you're not likely to need it for what you're doing right now) I have used rpctrace before, but portinfo, I will try it. is portinfo show a process's all port use log? not log current state dump the port name space? yes I found some names are not continuous. how this come out? continuous ? 101:send 103:send missing 102 some are freed a lot actually every RPC needs a reply port a temporary receive right to get replies from servers so we can reuse the name which are freed before of course ## IRC, freenode, #hurd, 2013-11-08 braunr: btw, portinfo --search turned out quite nice for detecting port leaks teythoon: something you added i guess ? braunr: just yesterday braunr: portinfo.c is full of useful ideas braunr: for example, with a little help of the target server (introspection protocol for libports) we could reliably detect leaks of ports managed with libports yes introspection is probably required ## IRC, freenode, #hurd, 2013-11-20 looking forward to using portinfo --search btw :) yeah, that turned out to be quite helpful that reminds me of the libports introspection idea :) introspection ? i mean that much, or a simple name for each port ? I thought about returning more information, like the port class class ? i don't think you should iirc, classes are deemed not very useful for hurdng they were supposed to be removed, leaving only buckets hurdng ... ? which seems more appropriate oh :) well, no need for an introspectino interface then http://www.gnu.org/software/hurd/hurd/ng.html introspection is a bit too much just look at the ports in the only port set then but something that would be reusable in lsof or /proc/*/maps would be very nice if you could just be a little more specific then I might just go and implement it ;) braunr: I don't think bucket information would be useful to the outside world; classes OTOH might worked fine with the mtab translator, let's do that again ;) antrik: buckets aren't, clearly antrik: more than classes, object types teythoon: well cat /proc/self/maps on linux ain't that the same? ;-) i don't know and i'm not sure it's that easy to make classes/types something global so simply returning a path, or even more generally a description string (sometimes a path) should be fine teythoon: just consider ports are frontends to objects yes what i'd like is something like object.toString() :p right something that would help us gather information about objects accessible from user applications what is known as open files on unix :) so 1) get a list of ports managed by libports, and 2) map those ports to strings describing the object ? the list isn't strictly necessary just associate a string description to ports portinfo and such already create port lists and fail if the port wasn't vaild? rihgt well if the port isn't valid, you can't succeed anyway but what is more likely is the port not supporting the operation yes in which case assume the empty string it may not be that straightforward imagine reply ports in select() for example so where would I put such an rpc ? i'm not sure for a time, i considered making it a kernel call it could be implemented in the signal thread too uh, oh, that's glibc land, right... ? in addition to "what are you waiting on", we could have "what's the name for that port" yes :) well not name port names refer to integers port desc yes i'm not sure how it should be done ideally, user applications should never have any reply ports and we could implement it all in libports select (and maybe others) make it hard how so ? such calls don't expect any kind of request other than what's intended if select gets something else than a select reply, it returns with an error so ? changing that to deal with unexpected requests makes the select implementation even harder than it is hum so, you don't want something like a mail server to fail because you used lsof right ? why would it get unexpected requests ? no a new rpc like "give me your description" would be unexpected for select servers properly demuxing messages would already reply they don't implement the interface select would return an error to its caller that's very different ah, well, ok, but if we put it in the signal thread, then lsof would talk to that port yes you mentioned that as a reason not to put it in libports ? yes normal applications don't use libports but they do have receive rights I see, yes ## IRC, freenode, #hurd, 2013-11-29 is the format of portinfo --search ORIG_PID => ... FOUND_PID => ... ? i think so, not sure atm 4 -> 5: 1 => 1: send (refs: 65534) :/ hm i don't see such a right in pid 1 no, frompid -> topid: port name in frompid => corresponding name in topid oh ok # IRC, freenode, #hurd, 2013-11-08 [[!tag open_issue_gdb]] what i'd like personally would be gdb to be able to track threads across address spaces, when it has the right to do so braunr, can gdb debug across threads? no the same is it can't follow system calls it can follow RPCs Then, I guess you have to debug multiple applications at once. can't* well the goal would be that right now, we debug them one at a time following our leads across applications it's a bit more tricky but not that hard braunr: that would be nice indeed we're talking about cross-address-space debugging which is needed only when objects are shared between multiple applications gdb can't do it but it can't do it on a monolithic system either people debug the kernel separately we debug our servers separately it's almost the same we don't debug all our servers, only those relevant in the code path that's only a few no it's worse for the monolithic kernel braunr, "Additionally, just tracking down a FS/write issue means examining the user space process, the block device service, VFS service, file system service and (possibly) the PCI service. If you get a blank on that, its time to look at the IPC service. This is often easier in a monolithic kernel." teythoon: depends crocket: agreed but again, such bugs are huge rare the only real class of cross-address-space bugs are leaks and leaks are easy to solve in practice # [[open_issues/Translate_FD_or_Port_to_File_Name]] # IRC, freenode, #hurd, 2014-01-30 btw, is there some alternative to strace? wanted to figure out why lightdm didn't find dbus. there's rpctrace but that's a bit different there's also sotruss from recent glibc