On Fri, Apr 17, 2026 at 08:02:08AM -0500, Brent Cook wrote:
> On Fri, Apr 17, 2026 at 7:53 AM Brent Cook <busterb@gmail.com> wrote:
> 
> > On Thu, Apr 16, 2026 at 11:14 PM Theo Buehler <tb@theobuehler.org> wrote:
> > >
> > > On Thu, Apr 16, 2026 at 09:47:54PM -0500, Brent Cook wrote:
> > > > I like to use btop to monitor resource usage on servers, but it wasn't
> > > > reporting per-core CPU usage correctly on OpenBSD. I reported and got
> > > > the issue fixed upstream, but it might be a while until the next
> > > > release, so I wanted to pull that diff into ports in the mean time:
> > > >
> > > > https://github.com/aristocratos/btop/pull/1587
> > > >
> > > The CPU one makes sense to me and it definitely improves things in the
> > > default display. However, the tool can't handle CPUs being added at
> > > runtime. If you remove S from hw.blockcpu (or toggle hw.smt 0 -> 1),
> > > a running btop throws an exception and dies:
> > >
> > > ERROR: Exception in runner thread -> Cpu:: -> collect() : vector
> > >
> > > I have no real opinion on whether that is acceptable or not. It doesn't
> > > look like an absolute blocker to me, but it doesn't seem ideal.
> > >
> > > You'd need to add REVISION=0 to the Makefile, and I would also add a link
> > > to your PR at the top of the patch.
> >
> > Here's v2, with a check made to active CPU count on each poll so the
> > stats vectors are resized and the UI is redrawn when that changes.
> >
> > My 4 core machine didn't crash for some reason in testing, but I think
>
> As I was feeding the chickens this morning, it came to me - I was
> testing with all of the cores/threads active, then removing them while
> btop was running, which meant the vectors were already sized big
> enough to avoid the crash. <facepalm>

Yeah, exactly. Good thing the chicken helped with my lack of clarity.

It's an 8 cores/16 threads AMD Ryzen 7 PRO 5850U where I ran into this.
The modified patch doesn't help. It still exits the same way if I start
btop with 8 cores and turn on smt while it's running. I don't think it's
a big deal, but it would be nice to fix eventually.

I'm ok with committing the patch in your first mail (the combination
of the upstreamed changes) with REVISION = 0.

Could you make one more change before commit, please? Since sparc64 now
has gcc 15, this allows it to build the package. It works.

Index: Makefile
===================================================================
RCS file: /cvs/ports/sysutils/btop/Makefile,v
diff -u -p -r1.8 Makefile
--- Makefile	28 Dec 2025 05:40:27 -0000	1.8
+++ Makefile	17 Apr 2026 13:31:42 -0000
@@ -12,7 +12,7 @@ PERMIT_PACKAGE=	Yes
 WANTLIB += ${COMPILER_LIBCXX} c kvm m
 
 # C++23
-COMPILER =	base-clang
+COMPILER =	base-clang ports-gcc
 
 BUILD_DEPENDS=	textproc/lowdown
 RUN_DEPENDS=	devel/desktop-file-utils \