2.4 crashes when try to exit app and mulitple threads active
peter at engcorp.com
Sun Mar 20 15:32:37 CET 2005
Maxwell Hammer wrote:
> On Sat, 19 Mar 2005 22:35:39 -0500, Peter Hansen wrote:
>>When you say "only one thread running", did you mean only
>>one monitor thread in addition to the main thread, or did
>>you really mean only the main thread was active at this time?
> I meant there was the main app and one thread. The problem
> does not occur when there are no threads running and the app
> has to exit.
Okay, but make sure you understand that it's not possible
to have "no threads running" unless your application has
already exited. There is *always* at least the main thread.
I think you know that, but it's confusing when you keep
talking as though the main thread doesn't exist.
>>The code in question is at the end of the MainThread's
>>__exitfunc() method, and normally this would be executing
>>only after all other threads had terminated, and should
>>be safe. It appears as though the _active dictionary that
>>tracks threads has been modified by someone else.
> That is what it looks like to me. It seems that the interpreter
> is trying to delete a non-existant thread
More than that, it's the MainThread in threading.py trying
to delete itself at exit, and that should always be possible
unless you've done Something Bad (or if this is indeed some
>>Can you post a small self-contained example that
>>reproduces the problem?
> This will be difficult to do...but perhaps if I give a summary:
> def main():
> ...wait for certain events
> ...based on events launch appropriate thread as follows:
> thread.start_new_thread(event_module.run, (StateValues, (job_parms)))
Unfortunately, pseudo code like that is of little help.
It does, however, raise a question. You are using the thread.py
module here, yet the exception is being generated as a result
of the MainThread object (that is created when you import
the threading.py module) trying to exit: how can it be that
threading.py is imported when you are using only the thread
module yourself? Other code that you aren't aware of? More
complexity than your snippets suggest?
You really need to reduce this down to a simple piece of code
that reproduces the problem if you hope to solve it. Race
conditions are just about the hardest thing in the world to
troubleshoot, and while you could report a bug here, without
code to reproduce the chances of someone finding and fixing
it are just about nil.
More information about the Python-list