From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- hurd/debugging.mdwn | 189 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 187 insertions(+), 2 deletions(-) (limited to 'hurd/debugging.mdwn') diff --git a/hurd/debugging.mdwn b/hurd/debugging.mdwn index ae9b7bef..e0da8e76 100644 --- a/hurd/debugging.mdwn +++ b/hurd/debugging.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2013 Free Software Foundation, -Inc."]] +[[!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 @@ -53,3 +53,188 @@ License|/fdl]]."]]"""]] 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 -- cgit v1.2.3