Devin Jeanpierre added the comment:
The patch I'm providing with this comment has a ... really hokey test case, and
a two line + whitespace diff for pystate.c . The objective of the patch is only
to have _current_frames report the correct frame for any live thread. It
continues to report dead
Devin Jeanpierre added the comment:
This bug also affects 2.7. The main problem I'm dealing with is
sys._current_frames will then return wrong stack frames for existing threads.
One fix to just this would be to change how the dict is created, to keep newer
threads rather than tossing them.
Antoine Pitrou added the comment:
Here is an updated patch which doesn't hold the lock while calling
PyThreadState_Clear(). It looks like it should be ok. Also, I've added some
comments.
--
Added file: http://bugs.python.org/file30137/tstates-afterfork2.patch
Roundup Robot added the comment:
New changeset 847692b9902a by Antoine Pitrou in branch 'default':
Issue #17094: Clear stale thread states after fork().
http://hg.python.org/cpython/rev/847692b9902a
--
nosy: +python-dev
___
Python tracker
Antoine Pitrou added the comment:
I've committed after the small change suggested by Charles-François. Hopefully
there aren't any applications relying on the previous behaviour.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: -Python
Antoine Pitrou added the comment:
if a
thread ends up being created/destroyed, I think we can get a deadlock
when trying to acquire the head lock. I think it should be turned into
an open call if possible.
How would you do that in a simple way?
Also, as noted by Stefan, shouldn't we also
Charles-François Natali added the comment:
Here is an updated patch.
_PyThreadState_DeleteExcept uses HEAD_LOCK: ISTM that
PyThreadState_Clear() can trigger arbitrary code execution: if a
thread ends up being created/destroyed, I think we can get a deadlock
when trying to acquire the head
Changes by Antoine Pitrou pit...@free.fr:
--
stage: - patch review
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17094
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17094
___
___
Python-bugs-list
Antoine Pitrou added the comment:
Isn't the thread state clearing subject to a race condition?
PyThreadState_Clear() will release a bunch of frames, deallocating arbitrary
objects and therefore potentially releasing the GIL. This lets the main thread
run and potentially spawn other threads,
Antoine Pitrou added the comment:
Here is an updated patch.
Note that I think this patch could break some programs. For example, if you
have a thread in your main process which has a database connection open,
deleting the thread state in a child process might shutdown the database
connection
Stefan Ring added the comment:
When I originally worked on this, I noticed that _PyThread_CurrentFrames also
iterates over all interpreters. Because I have no experience with or use for
multiple interpreters, I intentionally left it out of my patch, but shouldn't
it be taken into account for
Stefan Ring added the comment:
(Regarding your test)
I have also noticed in the past that joining threads after a fork has caused
hangs occasionally, although that might have resulted from the messed up
_current_frames.
--
___
Python tracker
Charles-François Natali added the comment:
Did you forget to attach the patch?
Oops...
--
Added file: http://bugs.python.org/file29295/tstate_after_fork.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17094
Antoine Pitrou added the comment:
hi Charles-François,
I'm attaching a patch doing the cleanup in PyEval_ReInitThreads(), with
test.
Did you forget to attach the patch?
--
___
Python tracker rep...@bugs.python.org
Charles-François Natali added the comment:
Thanks, it's surprising this was never noticed before.
Your patch has two issues:
- it doesn't clear the thread state before deleting it, which would leak the
frame, thread-specific dict, etc
- it only clears the thread states after the current thread
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +neologix, pitrou
versions: +Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17094
___
New submission from Stefan Ring:
After a fork, the list of thread states contains all the threads from before.
It is especially unfortunate that, at least for me, it usually happens that
threads created in the forked process reuse the same thread ids, and
sys._current_frames will then return
Changes by Stefan Ring stefan...@gmail.com:
Added file: http://bugs.python.org/file28925/test-fork-frames.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17094
___
19 matches
Mail list logo
