SIGSEGV - Karaf crash

I just had a SIGSEGV Karaf crash. I’m running OH5.1.4 on an Intel NUC with a Celeron. Zulu21 on Debian Bullseye. It’s been very stable for several years.

Anything further I can do to debug? Or monitor and see if it happens again? I haven’t made any significant changes to the OH system lately although I have updated some rules.


Host: Intel(R) Celeron(R) J4005 CPU @ 2.00GHz, 2 cores, 7G, Debian GNU/Linux 11 (bullseye)
Time: Sat May 16 16:15:02 2026 PDT elapsed time: 1312963.241609 seconds (15d 4h 42m 43s)

---------------  T H R E A D  ---------------

Current thread (0x00007f088d3577a0):  JavaThread "JmDNS(192-168-86-61.local.).Timer" daemon [_thread_in_Java, id=2222, stack(0x00007f08748ca000,0x00007f08749ca000) (1024K)]

Stack: [0x00007f08748ca000,0x00007f08749ca000],  sp=0x00000000a8a36fa8,  free space=18014262111569331k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000001020008145

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000001

Segmentation faults occur when a program attempts to access memory that isn’t theirs. Since Java manages it’s own memory automatically it’s basically impossible to cause it in the Java code.

Usually a seg fault in a java program is caused by JNI (some OH bindings do use external binary libraries like bluez for the Bluetooth binding). So that could be a source of you have such a binding installed.

Other causes are a bug in the underlying JVM or hardware issues. If it keeps happening, try a different JRE to run OH. If it keeps happening even then there might be a hardware problem.

If it rarely happens or only happened this one time, it could have just been a random flipped bit in ram.

Ambient radiation or even cosmic rays can flip bus in ram and while there is error correcting built into the chip, it doesn’t catch everything.