From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.2 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 27F301F406; Wed, 29 Nov 2023 22:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org; s=selector1; t=1701297655; bh=DhVl1aNFqm4kFzG9n9OiQM3sj5fyvlzqkEGvfo9z9NI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tuJxtyBXROIJuhOLDKvp2fTdmfzaEMB6ssMhMMNVZ1VGC66FTQq7vRO3JgvFdLCK1 VUjZaZUHJ4ECBr11fl+emXL+wnjBGUfX3ETbqTJa474L33BXta8M7jiMlF30VcO7xo 7XDtoRj1kyHA6xPIb+C/RbkseY2N2r0TnohDI/1A= Date: Wed, 29 Nov 2023 22:38:16 +0000 From: Eric Wong To: =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= Cc: meta@public-inbox.org Subject: Re: OpenBSD debugging Message-ID: <20231129223816.M525917@dcvr> References: <20231018170111+0200.599564-stepnem@smrk.net> <20231018190634.M893199@dcvr> <20231018211801+0200.254938-stepnem@smrk.net> <20231018212319.M51504@dcvr> <20231019104320+0200.219147-stepnem@smrk.net> <20231023195818.M543558@dcvr> <20231023222143+0200.165893-stepnem@smrk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231023222143+0200.165893-stepnem@smrk.net> List-Id: Štěpán Němec 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) 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.