On 3/17/26 14:40, Tomas Vondra wrote:
> On 3/17/26 13:17, Peter 'PMc' Much wrote:
>> ...
>>
>> The backtrace is disgusting - all interesting things are optimized
>> away. :(
>> So I am now quite clueless on how to proceed further, and could
>> really use some educated inspiration. I can not even say if this is
>> a postgres issue or a FreeBSD issue (but it doesn't happen to any
>> other program). I could probably rebuild the OS with -O0 - but is
>> this the best way to proceed?
>> (Filing a bug report against FreeBSD without specific reproduction
>> info would most likely just mean that it stays on my desk anyway.)
>>
>
> I agree it's hard to deduce anything from the backtraces with the
> interesting bits optimized out. Rebuilding the OS with -O0 might be an
> overkill, I'd probably start by building just Postgres. That'd at least
> give us some idea what happens there, you could inspect the memory
> context etc.
>
> I'm not a FreeBSD expert, but this seems a bit suspicious:
>
> frame #23: 0x0000000822ae79b6
> libthr.so.3`handle_signal(actp=0x0000000820c5c600, sig=30,
> info=0x0000000820c5c9f0, ucp=0x0000000820c5c680) at thr_sig.c:318:3
> frame #24: 0x0000000822ae6eba libthr.so.3`thr_sighandler(sig=30,
> info=0x0000000820c5c9f0, _ucp=0x0000000820c5c680) at thr_sig.c:261:2
>
> I mean, libthr seems to be a 1:1 with pthreads. Are you using threads in
> some way? Perhaps an extension using threads? That could cause weird
> failures, including weird SIGBUS ones.
>
BTW the first thing I'd try is testing memory with memtest86+ or a
similar tool. I don't know what hardware you're using, but I recently
dealt with weird failures on older machines, and it turned out to be
faulty RAM modules.
regards
--
Tomas Vondra
