On Sat, 19 Sep 2026 17:38:12 +0200,
Stuart Henderson <sthen@cvs.openbsd.org> wrote:
> 
> CVSROOT:	/cvs
> Module name:	ports
> Changes by:	sthen@cvs.openbsd.org	2026/09/19 09:38:12
> 
> Modified files:
> 	devel/libdispatch: Makefile distinfo 
> 	devel/libdispatch/patches: 
> 	                           patch-cmake_modules_DispatchCompilerWarnings_cmake 
> 	                           patch-src_CMakeLists_txt 
> Removed files:
> 	devel/libdispatch/patches: 
> 	                           patch-cmake_modules_SwiftSupport_cmake 
> 	                           patch-private_private_h 
> 	                           patch-src_event_event_c 
> 	                           patch-src_event_event_internal_h 
> 	                           patch-src_event_event_kevent_c 
> 	                           patch-src_event_workqueue_c 
> 	                           patch-src_init_c patch-src_internal_h 
> 	                           patch-src_io_c patch-src_queue_c 
> 	                           patch-src_shims_lock_c 
> 	                           patch-src_shims_lock_h 
> 	                           patch-src_swift_Source_swift 
> 	                           patch-src_swift_Wrapper_swift 
> 	                           patch-tests_CMakeLists_txt 
> 	                           patch-tests_bsdtestharness_c 
> 	                           patch-tests_dispatch_workqueue_c 
> 
> Log message:
> update to libdispatch-6.4.0
> 

This introduced regression in both net/64gram and net/tdesktop.

It started to consime 100% CPU on idle.

Inside gdb I see:

(gdb) bt
#0  kevent () at /tmp/-:2
#1  0x5479ad231d10bee9 in ?? ()
#2  0x000001dd874521ab in _dispatch_kq_poll () from /usr/local/lib/libdispatch.so.0.0
#3  0x000001dd87451b9b in _dispatch_kq_drain () from /usr/local/lib/libdispatch.so.0.0
#4  0x000001dd87451adb in _dispatch_event_loop_drain () from /usr/local/lib/libdispatch.so.0.0
#5  0x000001dd87445d02 in _dispatch_mgr_invoke () from /usr/local/lib/libdispatch.so.0.0
#6  0x000001dd87445c5b in _dispatch_mgr_thread () from /usr/local/lib/libdispatch.so.0.0
#7  0x000001dd874496fb in _dispatch_worker_thread () from /usr/local/lib/libdispatch.so.0.0
#8  0x000001de63074aa2 in _rthread_start (v=0x1) at /usr/src/lib/librthread/rthread.c:99
#9  0x000001ddecf9b88a in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:87
(gdb)

and inside ktrace I see a lot of

 24541 Telegram RET   kevent 1
 24541 Telegram CALL  kevent(17,0xc65660b3c80,1,0xc65660b3a00,16,0)
 24541 Telegram STRU  struct kevent { ident=18446744073709551360, filter=EVFILT_TIMER, flags=0x15<EV_ADD|EV_ENABLE|EV_ONESHOT>, fflags=0x13<NOTE_NSECONDS|NOTE_ABSTIME>, data=350184616671211, udata=0xc652f0e8180 }
 24541 Telegram STRU  struct kevent { ident=18446744073709551360, filter=EVFILT_TIMER, flags=0x15<EV_ADD|EV_ENABLE|EV_ONESHOT>, fflags=0<>, data=1, udata=0xc652f0e8180 }
 24541 Telegram RET   kevent 1
 24541 Telegram CALL  kevent(17,0xc65660b3c80,1,0xc65660b3a00,16,0)
 24541 Telegram STRU  struct kevent { ident=18446744073709551360, filter=EVFILT_TIMER, flags=0x15<EV_ADD|EV_ENABLE|EV_ONESHOT>, fflags=0x13<NOTE_NSECONDS|NOTE_ABSTIME>, data=350184616671211, udata=0xc652f0e8180 }
 24541 Telegram STRU  struct kevent { ident=18446744073709551360, filter=EVFILT_TIMER, flags=0x15<EV_ADD|EV_ENABLE|EV_ONESHOT>, fflags=0<>, data=1, udata=0xc652f0e8180 }
 24541 Telegram RET   kevent 1
 24541 Telegram CALL  kevent(17,0xc65660b3c80,1,0xc65660b3a00,16,0)
 24541 Telegram STRU  struct kevent { ident=18446744073709551360, filter=EVFILT_TIMER, flags=0x15<EV_ADD|EV_ENABLE|EV_ONESHOT>, fflags=0x13<NOTE_NSECONDS|NOTE_ABSTIME>, data=350184616671211, udata=0xc652f0e8180 }
 24541 Telegram STRU  struct kevent { ident=18446744073709551360, filter=EVFILT_TIMER, flags=0x15<EV_ADD|EV_ENABLE|EV_ONESHOT>, fflags=0<>, data=1, udata=0xc652f0e8180 }


Thus, seems that bump of SHARED_LIBS was missed on that update, it was good
for me, and allows to track it fast, but... can differences in ABI be a
reason of regression?

-- 
wbr, Kirill