Re: OpenBSD debugging

[Eric Wong <e@80x24.org>]

Štěpán Němec <stepnem@smrk.net> wrote:
> 
> I apologize for the late response.

No worries, I still have mails in other places from months
ago I've been meaning to get to :x

> On Mon, 23 Oct 2023 19:58:18 +0000
> Eric Wong wrote:
> 
> > Thanks for the info.  Just curious, what HW specs (ncpus, RAM)
> > is available on that system?  I wonder if that affects timing
> > somehow...
> 
> dmesg:
> https://dmesgd.nycbug.org/index.cgi?do=view&id=7357
> ncpus = 2 (so it's running the MP (multiprocessor) kernel), 1GB RAM

Alright, will keep that in mind.  OpenBSD doesn't seem to
benefit from having many cores and I stress out about the
test suite taking ~30s on my fastest HW.

> > Unfortunately, my *BSD debugging knowledge is far behind my
> > Linux; so I'm not sure how much help it'd be...
> 
> If nothing else, you could do some tests on an otherwise
> idle machine with good Internet connectivity (unless the
> connection issues you keep mentioning are mainly on your
> end, that is).

Yeah, it's mainly on my end, but seems improved in the past
2 weeks or so.

> > Some examples of things I miss on OpenBSD:
> >
> > * /proc/$PID/fdinfo/$FD_OF_EPOLL on Linux is immensely helpful
> >   for knowing what and how epoll is watching target FDs.  I'm
> >   not sure if there's a way to introspect kqueue like that
> 
> Yeah, most likely there isn't, though I'm not quite sure
> what exactly "like that" entails.  Care to expand a bit upon
> the immense usefulness mentioned, i.e., how this helps you
> specifically?

Knowing which EVFILT_*  and EV_* flags are in use for a
given target FD would be useful (analogous to the single
events: field printed in /proc/$pid/fdinfo/$epfd that
corresponds to struct epoll_event.events)

> OpenBSD fstat(1) prints the kqueue memory addresses, so I
> suppose a sufficiently determined individual could get
> arbitrary info from the running kernel based on that,
> although at that point there are probably better ways to get
> the address than running fstat...

I'll have to remember that next time I need to and RTFM for it.
I didn't know about the fstat(1) command until a few weeks ago
(horrible naming conflict with the fstat(2) syscall didn't
help with discovery)

<snip>  I'll keep the rest in mind next time I need it.

> > * Linux strace decodes more struct args info than kdump
> 
> strace is certainly more featureful, though in the specific
> case of kqueue/kevent I think kdump does show everything one
> would expect to see?

Ah, I think I was going off my FreeBSD experience, there;
OpenBSD does seem to decode sendmsg/recvmsg args well.
FreeBSD doesn't tell me which FDs are being sent/received
via SCM_RIGHTS, maybe that's improved in FreeBSD 14...

But yeah, still lots of work to do elsewhere; but OpenBSD seems
like an important driver in keeping Perl5 stable and
widely-installed.  *BSDs in general have been great at finding
bugs that might eventually impact my GNU/Linux systems.