The fixes in master work, in that there are no segmentation faults anymore,
however, now I regularly get this:
(gdb) where
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7f010403c537 in __GI_abort () at abort.c:79
#2 0x56469288b3c0 in debug_va_fatal (
>>#ifdef PIKE_USE_MACHINE_CODE
>> call_check_threads_etc();
>>#endif
>
>>I assume you have machine code enabled. call_check_threads_etc()
>
>Normally I do, however, to get to the bottom of this, I temporarily compiled
>with:
>gcc-9 -g -O1 -pipe -DPIKE_DEBUG=1
> --with-cdebug
Another core stacktrace (core5):
[New LWP 31798]
[New LWP 28691]
[New LWP 31695]
[New LWP 31738]
[New LWP 31703]
[New LWP 31730]
[New LWP 31707]
[New LWP 31717]
[New LWP 31711]
[New LWP 31725]
[New LWP 31699]
[New LWP 31673]
[New LWP 31367]
[New LWP 31799]
[New LWP 31694]
[New LWP 31715]
[New LWP
Tobias S. Josefowitz @ Pike developers forum wrote:
>>Am I reading those correctly that both are upon thread creation?
>First, nice backtrace. I think it's more that any thread started ever
>will have been started by thread creation, and that's what we're
>seeing here, not that this necessarily
>[New LWP 15651]
>[New LWP 15621]
>[New LWP 13738]
>[New LWP 15642]
>[Thread debugging using libthread_db enabled]
>Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>Core was generated by `/usr/local/bin/pike /home/spike.git/spike -n
>background'.
>Program terminated
Stephen R. van den Berg wrote:
>Well, this experiment failed. I took out my reverts locally, and now
>changed the diagnostic Pike_error() in case of the already-destructed call
>into a Pike_fatal(), in hopes of finding out when it is being triggered
>from the next coredump.
This is what I find:
