Mailing List Archive

[Thread-SIG] RE: tstate invalid crash with threads
I can confirm that we were seeing similar behavior under a highly threaded,
highly stressed situation. We backed off on the number of threads and
slowed things down as a workaround also. We couldn't trace it down to
Python, as we have a Java, C, Python mix that has too many suspects.

Scott Cothrell
Cisco Systems, Inc.

----- Original Message -----
From: Tim Peters <tim_one@email.msn.com>
To: Ray Loyzaga <ray@commsecure.com.au>; Guido van Rossum
<guido@python.org>; Thread-SIG <thread-sig@python.org>
Cc: <python-list@python.org>
Sent: Wednesday, June 09, 1999 12:18 AM
Subject: [Thread-SIG] RE: tstate invalid crash with threads


> Followups to the Thread-SIG, please.
>
> [Ray Loyzaga]
> > I have been playing with a multithreaded tcp based server for a while,
> > and during some serious stress testing continually hit a problem
> > involving the interpreter crashing with "Fatal Python error:
> > PyThreadState_Delete: invalid tstate".
> > ...
> > It appears to be a subtle race in PyThreadState_Delete ....
> > interestingly, if I uncomment the small sleep in "handle" in the server,
> > ie. make the server slower, it seems to work for ever ... 4m
transactions
> > before I gave up. I think the problem only comes if you are creating and
> > destroying threads quickly in parallel.
>
> PyThreadState_Delete is called from very few places, and one of them
strikes
> me as suspicious: at the end of threadmodule.c's t_bootstrap, we have:
>
> PyThreadState_Clear(tstate);
> PyEval_ReleaseThread(tstate);
> PyThreadState_Delete(tstate);
> PyThread_exit_thread();
>
> The suspicious thing here is that PyEval_ReleaseThread releases the global
> interpreter lock, so nothing is serializing calls to PyThreadState_Delete
> made from the following line. PyThreadState_Delete in turn does no
locking
> of its own either, but mutates a shared list.
>
> If this isn't plain wrong, it's certainly not plain right <wink>. Matches
> your symptoms, too (very rare blowups during high rates of thread death).
>
> Guido? I haven't been able to provoke Ray's problem under Win95, but the
> above just doesn't smell right.
>
> win95-didn't-crash-but-the-TAB-and-ESC-keys-did-swap-their-
> meanings!-ly y'rs - tim
>
>
>
> _______________________________________________
> Thread-SIG maillist - Thread-SIG@python.org
> http://www.python.org/mailman/listinfo/thread-sig
>
[Thread-SIG] RE: tstate invalid crash with threads [ In reply to ]
Scott Cothrell wrote:
>
> I can confirm that we were seeing similar behavior under a highly threaded,
> highly stressed situation. We backed off on the number of threads and
> slowed things down as a workaround also. We couldn't trace it down to
> Python, as we have a Java, C, Python mix that has too many suspects.
>

The locking code added to the create/destroy side of the threads
has yielded good results. On my stripped down server, which was crashing
after between 40,000 and 1.4M transactions managed 14.75M last night.
I will kill this and attempt to run my real task for a day or so,
but it seems to confirm a small race exists ....