reminder to check ports which you depend on against newer -current [was Re: zbar-0.23.93p1 segfaults, on -current 2026q3]

This issue below stems from an optimiser change made in clang 21 (and
gcc has a similar one), relating to C11 undefined behaviour with pointer
arithmetic involving negative integers cast to uintptr_t. A good reminder
that new compilers do things differently and can interact badly with
code that used to run without issues.

If you've been running older (pre July) -current snapshots and not got
round to updating recently, you might want to try that at a suitable
moment and make sure things which you depend on are still happy
following major compiler updates to both clang and gcc (clang in base
is used for most things on the more common archs, gcc in ports is used
for anything fortran on more common archs and for most of the ports
tree on sparc64).

If you're the sort of person that might sometimes run -current but
has stuck with 7.9-(release/stable) for now, that might be a good idea
too. Better to find things when you're more prepared for it than when
you're upgrading to 8.0 later and it'll be harder to track things down.


----- Forwarded message from Stuart Henderson <[email protected]> -----

From: Stuart Henderson <[email protected]>
Date: Mon, 17 Aug 2026 21:37:30 +0100
To: Mikolaj Kucharski <[email protected]>
Cc: [email protected], Jonathan Gray <[email protected]>
Subject: Re: zbar-0.23.93p1 segfaults, on -current 2026q3
Mail-Followup-To: Mikolaj Kucharski <[email protected]>, [email protected], Jonathan Gray <[email protected]>

On 2026/08/17 18:56, Mikolaj Kucharski wrote:
> Hi all.
> 
> I see consisent segmentation fault with `zbarimg -q --raw sample.png`
> command. I don't have usable core at present, so don't have any more
> info, but I am asking do you see the same? I took few random QR codes
> from the Internet and they all dump the core with above command.
> 
> I was using over the years zbarimg many times, so I didn't see this
> before. I see this on two separate machines.

I see it here too, also with other image formats, and with zbar compiled
with any of base llvm 22, ports llvm 21, ports gcc 16, on amd64 and
aarch64. Also same if I use packages from just before the ImageMagick
update.

Found a slightly older laptop and updated to 2026-05-15-0105
packages from ftp.hostserver.de archive, and zbar from there works.

Stepping forward the zbar package from 2026-05-30-0105 works,
updating just zbar to the package from 2026-06-01-0105 without
touching any other package it starts segfaulting.

The big thing that is likely to be in this window is LLVM 22.

Here's a backtrace from one of the times it crashed.

$ egdb zbarimg 
GNU gdb (GDB) 17.2
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd8.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from zbarimg...
Reading symbols from /usr/local/bin/.debug/zbarimg.dbg...
(gdb) set args --verbose=999 somefile.png
(gdb) r
Starting program: /usr/local/bin/zbarimg --verbose=999 somefile.png
_zbar_process_image: processing: Y800(30303859) 324x234 @0x2e14426f000
_zbar_scan_image: img_x+: 0000,0000 @0x2e14426f000
_zbar_scan_image: img_x-: 0323,0001 @0x2e14426f287

Program received signal SIGSEGV, Segmentation fault.
_zbar_scan_image (iscn=0x2e17de0dd80, img=0x2e0d0cfa310) at img_scanner.c:964
964			uint8_t d = *p;
(gdb) bt
#0  _zbar_scan_image (iscn=0x2e17de0dd80, img=0x2e0d0cfa310) at img_scanner.c:964
#1  0x000002e136700ae9 in zbar_scan_image (iscn=0x2e0d0d06880, img=0x0) at img_scanner.c:1128
#2  0x000002e1366fa5f1 in _zbar_process_image (proc=0x2e0d0d2b480, img=0x2e0d0cfa540) at processor.c:84
#3  0x000002e1366fc50c in zbar_process_image (proc=0x2e0d0d2b480, img=0x2e0d0cfa540) at processor.c:707
#4  0x000002de9426d5a6 in scan_image (filename=0x7743e50f5b7d "somefile.png") at zbarimg/zbarimg.c:209
#5  0x000002de9426ccf8 in main (argc=3, argv=0x7743e50f5908) at zbarimg/zbarimg.c:448
(gdb) frame 2
#2  0x000002e1366fa5f1 in _zbar_process_image (proc=0x2e0d0d2b480, img=0x2e0d0cfa540) at processor.c:84
84		nsyms = zbar_scan_image(proc->scanner, tmp);
(gdb) list
79		if (proc->syms) {
80		    zbar_symbol_set_ref(proc->syms, -1);
81		    proc->syms = NULL;
82		}
83		zbar_image_scanner_recycle_image(proc->scanner, img);
84		nsyms = zbar_scan_image(proc->scanner, tmp);
85		_zbar_image_swap_symbols(img, tmp);
86	
87		zbar_image_destroy(tmp);
88		tmp = NULL;
(gdb) p tmp
$1 = (zbar_image_t *) 0x2e0d0cfa310
(gdb) p *tmp
$2 = {
  format = 808466521,
  width = 324,
  height = 234,
  data = 0x2e14426f000,
  datalen = 75816,
  crop_x = 0,
  crop_y = 0,
  crop_w = 324,
  crop_h = 234,
  userdata = 0x0,
  cleanup = 0x2e1366f8780 <cleanup_ref>,
  refcnt = 1,
  src = 0x0,
  srcidx = -1,
  next = 0x2e0d0cfa540,
  seq = 0,
  syms = 0x2e0d0d2ffc0
}
(gdb) frame 3
#3  0x000002e1366fc50c in zbar_process_image (proc=0x2e0d0d2b480, img=0x2e0d0cfa540) at processor.c:707
707		rc = _zbar_process_image(proc, img);
(gdb) p img
$3 = (zbar_image_t *) 0x2e0d0cfa540
(gdb) list
702		rc = _zbar_processor_set_size(proc, zbar_image_get_width(img),
703					      zbar_image_get_height(img));
704	    if (!rc) {
705		zbar_image_scanner_enable_cache(proc->scanner, 0);
706		zbar_image_scanner_request_dbus(proc->scanner, proc->is_dbus_enabled);
707		rc = _zbar_process_image(proc, img);
708		if (proc->streaming)
709		    zbar_image_scanner_enable_cache(proc->scanner, 1);
710	    }
711	

On another machine which is closer to -current, recompiling zbar with
-O1 I still get SEGV, but with -O0 it works ok.

Belatedly thought to check issues/PRs and found
https://github.com/mchehab/zbar/pull/329 which would explain it,
and tests concur.

ok?

Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/zbar/Makefile,v
diff -u -p -r1.40 Makefile
--- Makefile	17 Aug 2026 19:36:49 -0000	1.40
+++ Makefile	17 Aug 2026 20:36:57 -0000
@@ -1,7 +1,7 @@
 COMMENT=	ZBar barcode reader

 DISTNAME=	zbar-0.23.93
-REVISION=	2
+REVISION=	3

 SHARED_LIBS=	zbar	0.1 \
 		zbargtk	0.1
Index: patches/patch-zbar_img_scanner_c
===================================================================
RCS file: patches/patch-zbar_img_scanner_c
diff -N patches/patch-zbar_img_scanner_c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ patches/patch-zbar_img_scanner_c	17 Aug 2026 20:36:57 -0000
@@ -0,0 +1,22 @@
+https://github.com/mchehab/zbar/pull/329, plus pull in stddef.h
+
+Index: zbar/img_scanner.c
+--- zbar/img_scanner.c.orig
++++ zbar/img_scanner.c
+@@ -33,6 +33,7 @@
+ #endif
+
+ #include <assert.h>
++#include <stddef.h> /* ptrdiff_t */
+ #include <stdlib.h> /* malloc, free */
+ #include <string.h> /* memcmp, memset, memcpy */
+
+@@ -862,7 +863,7 @@ static void zbar_send_code_via_dbus(zbar_image_scanner
+     do {                                 \
+ 	x += (dx);                       \
+ 	y += (dy);                       \
+-	p += (dx) + ((uintptr_t)(dy)*w); \
++	p += (ptrdiff_t)(dx) + (intptr_t)(dy) * (intptr_t)w; \
+     } while (0);
+
+ static void *_zbar_scan_image(zbar_image_scanner_t *iscn, zbar_image_t *img)


----- End forwarded message -----