paulheinsohn

Confirming this bug on 7.2.0 with a second, independent case — and adding two fix attempts that did NOT work, in case they help narrow it down. Same crash signature, on array Start (cmdStart): emhttpd[NNNNN]: segfault at 0 ip ... error 4 in libc-2.42.so[182387,...] "segfault at 0" + "error 4" = a NULL-pointer READ, i.e. emhttpd hands a NULL string to a libc string function while enumerating disk/pool config at Start. It reproduces 100% of the time and dies ~2 seconds after cmdStart with no emhttpd log output. Crucially it faults at the SAME libc offset (182387) every time. Environment: - Unraid 7.2.0, kernel 6.12.54, glibc 2.42 - Dual-socket Supermicro, LSI SAS3008 HBA - Parity is DISABLED on this array (mdNumDisabled=2), so slot 0 has no assigned device - Data disk is ZFS; a large multi-vdev ZFS pool is also configured as a pool Like the OP, /boot/config/disk.cfg is missing its slot-0 key set. The ONLY slot-0 keys present are: diskIdSlot.0="-" diskSpindownDelay.0="-1" diskSpinupGroup.0="" There is no diskId.0, no diskFsType.0, no diskSize.0, no diskName.0 — while slots 1-23 are fully populated (diskFsType.1="zfs", etc.). What I tried, and what happened: 1) Regenerate disk.cfg (the recommended workaround): backed up disk.cfg, renamed it out, rebooted. Unraid regenerated it — but the regenerated file STILL had no diskFsType.0 (with parity disabled, regen never writes a parity-slot fs key). Array Start still segfaulted. 2) Manually added diskFsType.0="" and diskSize.0="0" to disk.cfg and restarted emhttpd. Array Start STILL segfaulted, at the identical libc offset (182387). The takeaway from (2): because giving diskFsType.0 a valid value did not change or eliminate the crash, the NULL field being dereferenced is NOT diskFsType.0 — it's some other slot-0 / start-time config value that's missing when parity is disabled. It can't be pinned down from userspace on 7.2.0 (no gdb/strace shipped). The common trigger across both cases looks like a partially-defined slot 0 (parity slot present in config as diskIdSlot.0="-" but with no diskId/diskFsType/diskSize/diskName keys), which the 7.2.0 Start path dereferences without a NULL check. Data is 100% safe here — both pools import and mount cleanly with zero errors; only the emhttpd Start path is affected. I'm running services via a manual mount + docker bring-up outside emhttpd in the meantime. Happy to provide full diagnostics, the exact disk.cfg, or to run a debug emhttpd build / an rc with the added telemetry to identify which slot-0 field is dereferenced with parity disabled. Let me know what would be most useful. unraid-diagnostics-20260807-1023.zip