Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
___
Python-bugs-list mailing list
Charles-François Natali neolo...@free.fr added the comment:
I did a quick test (calling fork() from a subinterpreter), and as
expected, I couldn't reproduce the problem.
So I still favor an OOM condition making pthread_setspecific bail out
with ENOMEM, othe other option being a nasty libc bug.
Graham Dumpleton graham.dumple...@gmail.com added the comment:
Did anyone test this fix for case of fork() being called from Python sub
interpreter?
Getting a report of fork() failing in sub interpreters under mod_wsgi that may
be caused by this change. Still investigating.
Specifically
Charles-François Natali neolo...@free.fr added the comment:
Hello,
Did anyone test this fix for case of fork() being called from Python sub
interpreter?
Not specifically, unless it's part of the test suite.
Anyway, unless this problem is systematic - which I doubt - it
probably wouldn't
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Antoine, I wonder if we can restore PyThread_set_key_value to behave like a
canonical TLS api function (always setting) but fix the cases that want to set
if it has not already been set like the cases you mention.
It is very
Antoine Pitrou pit...@free.fr added the comment:
Antoine, I wonder if we can restore PyThread_set_key_value to behave
like a canonical TLS api function (always setting) but fix the cases
that want to set if it has not already been set like the cases you
mention.
It is very unorthodox to
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Ah, using the fallback implementation of tls? Surely this isn't a problem with
the pthreads tls, I'd be surprised if it retains TLS values after fork.
--
___
Python tracker
Charles-Francois Natali neolo...@free.fr added the comment:
Ah, using the fallback implementation of tls? Surely this isn't a
problem with the pthreads tls, I'd be surprised if it retains TLS values
after fork.
It surprised me too when I found that out, but it's really with the pthread
Changes by Charles-Francois Natali neolo...@free.fr:
Added file: http://bugs.python.org/file21802/tls_reinit_bis.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Antoine Pitrou pit...@free.fr added the comment:
You could add a new _PyGILState_ReInit() function and call it from
PyOS_AfterFork() or PyEval_ReInitThreads().
See attached tls_reinit.diff patch.
Thank you. I like this patch, except that _PyGILState_ReInit() should be
declared in the
Charles-Francois Natali neolo...@free.fr added the comment:
Thank you. I like this patch, except that _PyGILState_ReInit() should be
declared in the appropriate .h file, not in signalmodule.c.
I asked myself this question when writing the patch: what's the convention
regarding functions ?
Antoine Pitrou pit...@free.fr added the comment:
Thank you. I like this patch, except that _PyGILState_ReInit() should be
declared in the appropriate .h file, not in signalmodule.c.
I asked myself this question when writing the patch: what's the
convention regarding functions ? Should
Changes by Charles-Francois Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file21802/tls_reinit_bis.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Changes by Charles-Francois Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file21801/tls_reinit.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Changes by Charles-Francois Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file21678/thread_invalid_key.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Charles-Francois Natali neolo...@free.fr added the comment:
Here's an updated patch, tested on RHEL4U8.
--
Added file: http://bugs.python.org/file21804/tls_reinit.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
Changes by Antoine Pitrou pit...@free.fr:
--
dependencies: -multiprocessing generates a fatal error
stage: - commit review
superseder: - multiprocessing generates a fatal error
versions: +Python 2.7, Python 3.1, Python 3.3
___
Python tracker
Changes by Antoine Pitrou pit...@free.fr:
--
superseder: multiprocessing generates a fatal error -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Roundup Robot devnull@devnull added the comment:
New changeset f6feed6ec3f9 by Antoine Pitrou in branch '2.7':
Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*
http://hg.python.org/cpython/rev/f6feed6ec3f9
--
nosy: +python-dev
Roundup Robot devnull@devnull added the comment:
New changeset 7b7ad9a88451 by Antoine Pitrou in branch '3.2':
Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*
http://hg.python.org/cpython/rev/7b7ad9a88451
New changeset c8f283cd3e6e by Antoine Pitrou in branch
Antoine Pitrou pit...@free.fr added the comment:
It should be fixed now! Thank you.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
Charles-Francois Natali neolo...@free.fr added the comment:
Not necessarily. You can have several interpreters (and therefore several
thread states) in a single thread, using Py_NewInterpreter(). It's used by
mod_wsgi and probably other software. If you overwrite the old value with the
Antoine Pitrou pit...@free.fr added the comment:
Well, after fork, all threads have exited, so you'll be running on the
behalf of the child process' main - and only - thread, so by
definition you can't access other threads' thread-specific data, no?
A rather good point :)
How about deleting
Charles-Francois Natali neolo...@free.fr added the comment:
How about deleting the mapping (pthread_key_delete) and recreating it
from scratch, then?
Sounds good.
So the idea would be to retrieve the current thread's tstate, destroy the
current autoTLSkey, re-create it, and re-associate the
Antoine Pitrou pit...@free.fr added the comment:
How about deleting the mapping (pthread_key_delete) and recreating it
from scratch, then?
Sounds good.
So the idea would be to retrieve the current thread's tstate, destroy
the current autoTLSkey, re-create it, and re-associate the
Charles-Francois Natali neolo...@free.fr added the comment:
So, if it is possible to fix this and remove this weird special case and cast
it into the abyss, then by all means, you have my 10 thumbs up. Not that it
counts for much :)
Me too.
We still have a couple hundred RHEL4/5 boxes at
Antoine Pitrou pit...@free.fr added the comment:
I think that if we were to call PyThread_set_key_value twice on the
same key it's either an error, or we want the last version to be
stored, not the old one.
Not necessarily. You can have several interpreters (and therefore several
thread
Charles-Francois Natali neolo...@free.fr added the comment:
This is due to a bug in the TLS key management when mixed with fork.
Here's what happens:
When a thread is created, a tstate is allocated and stored in the thread's TLS:
thread_PyThread_start_new_thread - t_bootstrap -
Changes by Charles-Francois Natali neolo...@free.fr:
Added file: http://bugs.python.org/file21677/test_specific.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Changes by Charles-Francois Natali neolo...@free.fr:
--
keywords: +patch
Added file: http://bugs.python.org/file21678/thread_invalid_key.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
Charles-Francois Natali neolo...@free.fr added the comment:
Note: this seems to be fixed in RHEL6.
(Sorry for the noise).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Now, I'd be super happy to see this strange semantics of PyThread_set_key_value
go away. Its very un-standard and complicates the mapping from an native
implementation to the python one.
But I think I did once bring up this
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
What is the line that the parent process is executing? Line numbers don't seem
to match any more.
And is it possible to set a breakpoint in the child process where the fatal
error is triggered? It would be good to know what is
Sandro Tosi sandro.t...@gmail.com added the comment:
Is someone still able to replicate this crash? I'm not, with a fresh built 3.2
and default (3.3), --with-pydebug enabled. Brian confirmed on msg132418 that he
can't any longer replicate it.
--
nosy: +sandro.tosi
Dave Malcolm dmalc...@redhat.com added the comment:
I tried again, and I'm still able to reproduce this bug on a RHEL5 box with
cpython --with-pydebug as of a recent checkout (69030:00217100b9e7 as it
happens):
$ ./python -c import multiprocessing.managers ; mpp = multiprocessing.Pool(4);
sm
Dave Malcolm dmalc...@redhat.com added the comment:
I spent some time bisecting the SVN history in the py3k branch, and believe
that r84914 is the commit that introduced this issue.
Details:
Trying on 4-core i386 RHEL 5 box
$ svn up -r REV
$ make clean ; make
(configured
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +krisvale
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
r84914 was the implementation of issue 9786 (Native TLS support for pthreads)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
Dave Malcolm dmalc...@redhat.com added the comment:
This appears to be happening in a child process when the parent process is
running:
Lib/multiprocessing/util.py, line 255, in _exit_function ()
Liberally adding printf() and getpid() calls in various places, seems to always
happen when
Changes by Dave Malcolm dmalc...@redhat.com:
--
title: test_concurrent_futures crashes with Fatal Python error: Invalid thread
state for this thread - test_concurrent_futures crashes with --with-pydebug
on RHEL5 with Fatal Python error: Invalid thread state for this thread
40 matches
Mail list logo
