In normal operation with pthreads when PyThread_release_lock is called and it calls PyThread_acquire_lock in the "sanity check" errno will be set to 11 and left that way.  It seems like this should not happen so thread switches don't arbitrarily and w/o much reason alter the program state.

I ran into this working on a threaded debugger where a lock is used internally.  The debugger I'm writing now saves/restores errno in its tracer but it seems like there is potential for this bug all over the place.

Stephan,
Can you provide a test case?

If you are at PyCon 2009 sprints, try to see if you can find John
Ehresman in the Python Core sprint to see it happen at line 115 of
threadops.c in the Wing 3.2 source base.  If you're not there or can't
find him, I'll try to make a small example later.  Feel free to email me
directly also at sdeibel at wingware dot com. Note I saw this w/
pthreads and it may be that it does not occur under other threading
implementations.

Here is a patch against Python 2.6.1 that restores errno after the
"sanity check" in lock_PyThread_release_lock in Modules/threadmodule.c.

A potential controversy is whether it should be done here or in
thread_pthread.h but I believe that we should protect errno from
spurious change by _any_ threading model that objects to this internal 
attempt to acquire an already acquired lock.

Any possibility of a test case?

He he, well my attempts at replicating this on Linux and OS X failed
using Python 2.3->2.6 so I'm closing this bug.  I'm uploading the test
case for what it's worth.  My best guess at what happened is that there
was some interaction w/ older gdb, since I do know that I stepped
through code in gdb to see this happen, or perhaps it was on older
pthreads.  The bug report dates from what I believe I had another
desktop computer and older Linux version on that.  Thanks for spurring
me on to looking at this again and in more detail.