> - how do you know the crash really happens because of thread 5?

All other threads are blocked on locks or condition variables, it's
the only runnable thread.

> Another question: are threads being started or stopped while the thread local object is being deleted?

From the stack trace, thread 2 is being stopped.

I guess the problem is similar to above: thread 2 is in the middle of
stopping, its TLS dict is deallocated, which triggers the thread local
object deallocation, which releases the GIL. Thread 5 becomes running,
and must somehow access thread 2 tstate.
It would be much easier with a backtrace, though.