STINNER Victor added the comment:
There is no activity since 2013. I guess that the user found a way to
workaround this crash, or managed to get it fixed. I close the issue.
--
nosy: +vstinner
resolution: -> out of date
stage: -> resolved
status: open -> closed
Jan Safranek added the comment:
On 05/09/2013 09:07 AM, Jan Safranek wrote:
Jan Safranek added the comment:
On 05/07/2013 05:32 PM, Antoine Pitrou wrote:
Jan, one possibility would be for Pegasus to stop unloading Python,
it seems.
It is always possibility. Actually, Pegasus plugin is
Antoine Pitrou added the comment:
Le mardi 14 mai 2013 à 15:28 +, Jan Safranek a écrit :
libpython2.7.so is not unloaded because python extensions, e.g.
/usr/lib64/python2.7/lib-dynload/_heapq.so depend on it. And _heapq.so
was dlopenened by Python and it was not dlclosed - glibc does not
Jan Safranek added the comment:
On 05/07/2013 06:06 PM, Antoine Pitrou wrote:
a significant amount of static data inside CPython actually survives
Py_Finalize :-/
As a solution, would it be possible to wipe all registered types in
Py_Finalize?
Jan
--
Jan Safranek added the comment:
On 05/07/2013 05:32 PM, Antoine Pitrou wrote:
Jan, one possibility would be for Pegasus to stop unloading Python,
it seems.
It is always possibility. Actually, Pegasus plugin is just a shared
object (.so) and the .so is linked with Python. Pegasus calls
New submission from Jan Safranek:
I have Python 2.7.4 running on Fedora Rawhide and I get segmentation fault with
following backtrace:
#0 0x7f73f69ca5f1 in clear_weakref (self=0x7f73ff515c00) at
Objects/weakrefobject.c:56
#1 weakref_dealloc (self=0x7f73ff515c00) at
Jan Safranek added the comment:
I can reproduce the crash in very unusual setup:
1. OpenPegasus (http://www.openpegasus.org/), for this bug we may consider it
just a network daemon, listening on TCP port. When a request comes, it is
eventually processed by a provider (= something like plugin).
Jan Safranek added the comment:
Bisecting Python mercurial repository, I found the patch which causes the crash:
changeset: 80762:7e771f0363e2
branch: 2.7
parent: 80758:29627bd5b333
user:Antoine Pitrou solip...@pitrou.net
date:Sat Dec 08 21:15:26 2012 +0100
summary:
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +benjamin.peterson, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17922
___
___
Antoine Pitrou added the comment:
Hi Jan,
First, have you seen the following message on that bug report:
http://bugs.python.org/issue16602#msg177180
Second, I would suggest you build a debug build of Python (./configure
--with-pydebug), it should give you more information in the stack trace,
Jan Safranek added the comment:
First, have you seen the following message on that bug report:
http://bugs.python.org/issue16602#msg177180
I'm reading it now... I searched for PyWeakref_GET_OBJECT in cmpi-bindings and
both occurrences generated by SWIG and both look safe.
Is it
Antoine Pitrou added the comment:
Debugging with gdb is quite a problem, I have gdb linked with distribution
Python
2.7.4 and it doesn't cooperate with my custom built python, which I have in
LD_LIBRARY_PATH
Ok. Still, you should be able to inspect the variables at the crash point.
Could
Jan Safranek added the comment:
Could you try to inspect the `self` variable inside weakref_dealloc,
especially `self-wr_object` and its Py_TYPE() value? Also, what is the
value of Py_REFCNT(self-wr_object)?
in weakref_dealloc at Objects/weakrefobject.c:106:
(gdb) p *self
$1 = {_ob_next =
Antoine Pitrou added the comment:
(gdb) p *((PyWeakReference*)self)-wr_object
$9 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x0}
If I am reading Py_TYPE right, Py_TYPE(self-wr_object) must be 0
(=NULL).
Well, no, it should *always* be non-NULL (and it's a strong
Amaury Forgeot d'Arc added the comment:
swigpyobject_type is a static PyTypeObject variable (similar to all static
PyTypeObject structures we write in extension modules, but inside a function)
It should never be deallocated... There may be a refcount issue with this
object.
--
nosy:
Antoine Pitrou added the comment:
swigpyobject_type is a static PyTypeObject variable (similar to all
static PyTypeObject structures we write in extension modules, but
inside a function)
It should never be deallocated... There may be a refcount issue with
this object.
Even if it's
Amaury Forgeot d'Arc added the comment:
Right. But this is an embedded interpreter, and SWIG does not call
PyType_Ready() again; the old type is returned instead.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17922
Antoine Pitrou added the comment:
But this is an embedded interpreter, and SWIG does not call
PyType_Ready() again; the old type is returned instead.
Yuk. Perhaps Dave Beazley can give us some insights here?
Jan, one possibility would be for Pegasus to stop unloading Python, it seems.
Jan Safranek added the comment:
Right. But this is an embedded interpreter, and SWIG does not call
PyType_Ready() again; the old type is returned instead.
Python crashes in Py_Initialize(). SWIG_init() is called right after it.
So even if SWIG calls PyType_Ready, it would be too late.
Why
Amaury Forgeot d'Arc added the comment:
Python remembers SWIG types because SWIG generates code like this:
PyTypeObject * SwigPyObject_TypeOnce(void) {
static PyTypeObject swigpyobject_type;
static int type_init = 0;
if (!type_init) {
// ... initialization code ...
Antoine Pitrou added the comment:
Why python remembers SWIG types after Py_Finalize() in the first
place?
I want to destroy it and start with fresh instance.
Because a significant amount of static data inside CPython actually
survives Py_Finalize :-/
--
21 matches
Mail list logo
