1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
|
[[!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
<hacklu> braunr: I don't understand your question totally, but I want to
know how do you do this inspecting? <braunr> i have a small test program
that creates a thread, and inspect its state before any thread dies
<braunr> i use portinfo
<braunr> and rpctrace
<braunr> (there is also vminfo but you're not likely to need it for what
you're doing right now)
<hacklu> I have used rpctrace before, but portinfo, I will try it.
<hacklu> is portinfo show a process's all port use log?
<braunr> not log
<braunr> current state
<hacklu> dump the port name space?
<braunr> yes
<hacklu> I found some names are not continuous. how this come out?
<braunr> continuous ?
<hacklu> 101:send 103:send
<hacklu> missing 102
<braunr> some are freed
<braunr> a lot actually
<braunr> every RPC needs a reply port
<braunr> a temporary receive right to get replies from servers
<hacklu> so we can reuse the name which are freed before
<braunr> of course
## IRC, freenode, #hurd, 2013-11-08
<teythoon> braunr: btw, portinfo --search turned out quite nice for
detecting port leaks
<braunr> teythoon: something you added i guess ?
<teythoon> braunr: just yesterday
<teythoon> braunr: portinfo.c is full of useful ideas
<teythoon> 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
<braunr> yes introspection is probably required
## IRC, freenode, #hurd, 2013-11-20
<braunr> looking forward to using portinfo --search btw :)
<teythoon> yeah, that turned out to be quite helpful
<teythoon> that reminds me of the libports introspection idea :)
<braunr> introspection ?
<braunr> i mean
<braunr> that much, or a simple name for each port ?
<teythoon> I thought about returning more information, like the port class
<braunr> class ?
<braunr> i don't think you should
<braunr> iirc, classes are deemed not very useful for hurdng
<braunr> they were supposed to be removed, leaving only buckets
<teythoon> hurdng ... ?
<braunr> which seems more appropriate
<braunr> oh :)
<teythoon> well, no need for an introspectino interface then
<braunr> http://www.gnu.org/software/hurd/hurd/ng.html
<braunr> introspection is a bit too much
<teythoon> just look at the ports in the only port set then
<braunr> but something that would be reusable in lsof
<braunr> or /proc/*/maps
<braunr> would be very nice
<teythoon> if you could just be a little more specific then I might just go
and implement it ;)
<antrik> braunr: I don't think bucket information would be useful to the
outside world; classes OTOH might
<teythoon> worked fine with the mtab translator, let's do that again ;)
<braunr> antrik: buckets aren't, clearly
<braunr> antrik: more than classes, object types
<braunr> teythoon: well cat /proc/self/maps on linux
<antrik> ain't that the same? ;-)
<braunr> i don't know
<braunr> and i'm not sure it's that easy to make classes/types something
global
<braunr> so simply returning a path, or even more generally a description
string (sometimes a path)
<braunr> should be fine
<braunr> teythoon: just consider ports are frontends to objects
<teythoon> yes
<braunr> what i'd like is something like object.toString() :p
<teythoon> right
<braunr> something that would help us gather information about objects
accessible from user applications
<braunr> what is known as open files on unix :)
<teythoon> so 1) get a list of ports managed by libports, and 2) map those
ports to strings describing the object ?
<braunr> the list isn't strictly necessary
<braunr> just associate a string description to ports
<braunr> portinfo and such already create port lists
<teythoon> and fail if the port wasn't vaild?
<teythoon> rihgt
<braunr> well
<braunr> if the port isn't valid, you can't succeed anyway
<braunr> but
<braunr> what is more likely is the port not supporting the operation
<teythoon> yes
<braunr> in which case assume the empty string
<braunr> it may not be that straightforward
<braunr> imagine reply ports in select() for example
<teythoon> so where would I put such an rpc ?
<braunr> i'm not sure
<braunr> for a time, i considered making it a kernel call
<braunr> it could be implemented in the signal thread too
<teythoon> uh, oh, that's glibc land, right... ?
<braunr> in addition to "what are you waiting on", we could have "what's
the name for that port"
<braunr> yes
<braunr> :)
<braunr> well not name
<braunr> port names refer to integers
<braunr> port desc
<teythoon> yes
<braunr> i'm not sure how it should be done
<braunr> ideally, user applications should never have any reply ports
<braunr> and we could implement it all in libports
<braunr> select (and maybe others) make it hard
<teythoon> how so ?
<braunr> such calls don't expect any kind of request
<braunr> other than what's intended
<braunr> if select gets something else than a select reply, it returns with
an error
<teythoon> so ?
<braunr> changing that to deal with unexpected requests makes the select
implementation even harder than it is
<braunr> hum so, you don't want something like a mail server to fail
because you used lsof right ?
<teythoon> why would it get unexpected requests ?
<teythoon> no
<braunr> a new rpc like "give me your description" would be unexpected for
select
<braunr> servers properly demuxing messages would already reply they don't
implement the interface
<braunr> select would return an error to its caller
<braunr> that's very different
<teythoon> ah, well, ok, but if we put it in the signal thread, then lsof
would talk to that port
<braunr> yes
<teythoon> you mentioned that as a reason not to put it in libports ?
<braunr> yes
<braunr> normal applications don't use libports
<braunr> but they do have receive rights
<teythoon> I see, yes
## IRC, freenode, #hurd, 2013-11-29
<braunr> is the format of portinfo --search ORIG_PID => ... FOUND_PID =>
... ?
<teythoon> i think so, not sure atm
<braunr> 4 -> 5: 1 => 1: send (refs: 65534)
<braunr> :/
<braunr> hm i don't see such a right in pid 1
<teythoon> no, frompid -> topid: port name in frompid => corresponding name
in topid
<braunr> oh ok
# IRC, freenode, #hurd, 2013-11-08
[[!tag open_issue_gdb]]
<braunr> 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
<crocket> braunr, can gdb debug across threads?
<braunr> no
<braunr> the same is it can't follow system calls
<braunr> it can follow RPCs
<crocket> Then, I guess you have to debug multiple applications at once.
<braunr> can't*
<braunr> well
<braunr> the goal would be that
<braunr> right now, we debug them one at a time
<braunr> following our leads across applications
<braunr> it's a bit more tricky but not that hard
<teythoon> braunr: that would be nice indeed
<braunr> we're talking about cross-address-space debugging
<braunr> which is needed only when objects are shared between multiple
applications
<crocket> gdb can't do it
<braunr> but it can't do it on a monolithic system either
<braunr> people debug the kernel separately
<braunr> we debug our servers separately
<braunr> it's almost the same
<braunr> we don't debug all our servers, only those relevant in the code
path
<braunr> that's only a few
<teythoon> no it's worse for the monolithic kernel
<crocket> 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."
<braunr> teythoon: depends
<braunr> crocket: agreed
<braunr> but again, such bugs are huge
<braunr> rare
<braunr> the only real class of cross-address-space bugs are leaks
<braunr> and leaks are easy to solve in practice
# [[open_issues/Translate_FD_or_Port_to_File_Name]]
# IRC, freenode, #hurd, 2014-01-30
<pere> btw, is there some alternative to strace? wanted to figure out why
lightdm didn't find dbus.
<pochu> there's rpctrace but that's a bit different
<youpi> there's also sotruss from recent glibc
|
