Stephen R. van den Berg wrote:
>Stephen R. van den Berg wrote:
>>Agreed. The trouble is finding them. The problems are triggered by
>>destruct-races, and therefore hard to reproduce under controlled
>>circumstances.
>I might have found something, in the Shuffler. The error (if it actually is
>[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
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
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:
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
>>#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
