Roundup Robot added the comment:
New changeset 5aa1bc2f00ad by Antoine Pitrou in branch 'default':
Issue #13992: The trashcan mechanism is now thread-safe. This eliminates
http://hg.python.org/cpython/rev/5aa1bc2f00ad
--
___
Python tracker
Georg Brandl added the comment:
Picked as 5aa1bc2f00ad.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Roundup Robot added the comment:
New changeset 5a2ef447b80d by Antoine Pitrou in branch '2.7':
Issue #13992: The trashcan mechanism is now thread-safe. This eliminates
http://hg.python.org/cpython/rev/5a2ef447b80d
--
nosy: +python-dev
___
Python
Roundup Robot added the comment:
New changeset e72cda3f40a2 by Antoine Pitrou in branch '3.2':
Issue #13992: The trashcan mechanism is now thread-safe. This eliminates
http://hg.python.org/cpython/rev/e72cda3f40a2
New changeset 6bcaba9e8df2 by Antoine Pitrou in branch 'default':
Issue #13992:
Antoine Pitrou added the comment:
Georg, I think this should go in 3.3.0, what do you think?
--
resolution: - fixed
stage: patch review - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
Antoine Pitrou added the comment:
Oops, forgot to make Georg nosy.
Georg, I think this should go in 3.3.0, what do you think?
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
Changes by Antoine Pitrou pit...@free.fr:
--
Removed message: http://bugs.python.org/msg169891
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +benjamin.peterson
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
Manu Cupcic added the comment:
Hi,
Antoine, thank you for the patch you proposed. It indeed fixed the bug I was
seeing (I ran a job that usually crashes in one to two hours over the week end
and it is still running).
I am not sure what we should do now. Can this patch be integrated as is ?
Antoine Pitrou added the comment:
I am not sure what we should do now. Can this patch be integrated as is
? What can I do to help ?
Well, you already helped by testing it, thank you.
I have to add a test case to the patch, then hopefully it can be committed.
--
stage: - patch
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Manu Cupcic added the comment:
I am testing this patch right now. Will report back.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Antoine Pitrou added the comment:
Can someone witnessing the problem try to apply the attached patch?
--
keywords: +patch
Added file: http://bugs.python.org/file27065/trashcan-2.7.patch
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
(for context about the patch, see my hypothesis at
http://mail.python.org/pipermail/python-dev/2012-August/121533.html )
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
Francois VISCONTE added the comment:
Hi,
Following Manu's information I complete with what you asked.
I repeated the bug described by Manu, with the same software in exactly the
same conditions.
The corrupted object is one of our SQLAlchemy mapped object. Chances are that
the bug came from
Charles-François Natali added the comment:
(gdb) p op
$12 = (PyObject *) 0x4dc7bc0
Don't you have GDB 7, to decode Python objects ?
You can check the type of the object with :
p op-ob_type.tp_name
thread all apply bt is going to be very long no ? Could you tell me what you
want to know
Manu Cupcic added the comment:
I am also hitting this issue.
I have been able to reproduce it in python 2.5 and 2.7, on debian 6 (64 bits)
Exactly like the reporter, I am making extensive use of threads. I am also
using SQLalchemy.
All my threads but one are waiting (probably for the GIL) :
Charles-François Natali added the comment:
Is there something else I can do to help resolve this bug ? I can help
debugging this, but I am not sure how to proceed. I have a --with-pydebug
interpreter stopped at the segfault in gdb.
Could you post the output of :
p op
and
thread apply
Manu Cupcic added the comment:
(gdb) p op
$12 = (PyObject *) 0x4dc7bc0
thread all apply bt is going to be very long no ? Could you tell me what you
want to know that is not in info threads maybe ? I can definitely post it here,
but it's going to be a lot of output.
I can be available on IRC
Charles-François Natali neolo...@free.fr added the comment:
I'm running out of ideas to debug this, maybe Antoine or Amaury can help :-)
One last idea (not sure it will work though):
If Channel's finalizer gets called twice, inside Channel.__del__, you
could save a string representation of the
Charles-François Natali neolo...@free.fr added the comment:
(I'm adding Antoine to the noisy list).
You could maybe try building with '--without-pymalloc', and run under valgrind
(--suppressions=Misc/valgrind-python.supp), see
Aaron Staley usaa...@gmail.com added the comment:
Unfortunately, my application is running so slow under valgrind that behavior
is changing, namely the sockets are all timing out.
--
___
Python tracker rep...@bugs.python.org
Charles-François Natali neolo...@free.fr added the comment:
Unfortunately, my application is running so slow under valgrind that
behavior is changing, namely the sockets are all timing out.
Did you see any invalid read/write?
By the way, a google search returned me this:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
and I do occasionally use PyThreadState_SetAsyncExc to asynchronously
terminate threads.
Did you write an extension module for this? It is possible that there is a
refcount error there.
--
nosy: +amaury.forgeotdarc
Aaron Staley usaa...@gmail.com added the comment:
I see no invalid read/write. Only warnings are some conditional jump depends on
uninitialized value in pycrypto's libraries very early on though.
The link seems to be a different bug from mine. I did test in python 2.6.7 and
the crash still
Aaron Staley usaa...@gmail.com added the comment:
BTW, I take back what I said about using PyThreadState_SetAsyncExc. Turns out
I had a bug where this function would never succeed (was always returning 0).
--
___
Python tracker
Aaron Staley usaa...@gmail.com added the comment:
Active extension modules are MySQL-python, numpy, and crypto.
Here is the output from the non-optimized debug build. Slightly different
trace, but still some sort of deallocator crashing AFAIK:
#0 0x0046247c in _Py_ForgetReference
Charles-François Natali neolo...@free.fr added the comment:
Possibly a double free?
(gdb) p *op
$5 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x3c6d9f0}
It indeed looks like a double free (see the previous and next pointers
have already been set to NULL).
Could you check
Aaron Staley usaa...@gmail.com added the comment:
As far as I can tell, no other thread is active. Their backtraces are all
either:
#0 0x7f283dedd300 in sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00519295 in PyThread_acquire_lock (lock=0xe7dd50, waitflag=1) at
Aaron Staley usaa...@gmail.com added the comment:
I should note that my program is also affected by this bug:
http://bugs.python.org/issue13817
(couldn't isolate it until I used the pydebug configure info).
--
___
Python tracker
Aaron Staley usaa...@gmail.com added the comment:
Used latest mercurial 2.7 branch and segfault still occurs.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
Aaron Staley usaa...@gmail.com added the comment:
Also, the only particular things by code does is have a lot of threads (100+),
holds open many ssh connections (with paramiko) and I do occasionally use
PyThreadState_SetAsyncExc to asynchronously terminate threads.
--
New submission from Aaron Staley usaa...@gmail.com:
Am frequently getting segmentation faults with my python program. I am
utilizing heavy use of threading and sockets.
All sorts of ones are showing in syslog:
kernel: [7763578.475590] python[10097]: segfault at 88e5a0 ip 0088e5a0
sp
Aaron Staley usaa...@gmail.com added the comment:
For some more context:
Python 2.7.2
Running on Amazon EC2
Linux 3.0.0-14-virtual x86_64 in ubuntu 11.10
170 threads in this particular core dump (another similar crash has 135)
--
___
Python tracker
Charles-François Natali neolo...@free.fr added the comment:
The crash occurs in an oject's destructor.
Are you using any third-party module (lsof/pmap can help)?
Also, it'd help if you tried reproducing the crash with a debug build
(./configure --with-pydebug make).
--
nosy:
35 matches
Mail list logo
