Ipython dies

I’ve got a strange behaviour …
I try (everything newly compiled):
Python 2.7.3 (default, Feb 22 2013, 21:49:22)
IPython 0.13.1 – An enhanced Interactive Python.
ROOT “v5-34-00-patches” (as of today)
and, when I try “ipython”, I get: [code]----------------------------------------------------------------------
In [1]: from ROOT import *

In [2]: gROOT
Out[2]: <ROOT.TROOT object (“PyROOT”) at 0xb5cbcf40>

In [3]: (… I PRESSED Ctrl-D HERE …)
Do you really want to exit ([y]/n)? y
(… NO PROBLEM HERE … I get the shell prompt …)

In [1]: from ROOT import *

In [2]: (… I PRESSED Ctrl-D HERE …)
Do you really want to exit ([y]/n)? y

*** Break *** segmentation violation

===========================================================
There was a crash (#8 0xb587e52b in SigHandler(ESignals) () from /…/v5-34-00-patches/lib/libCore.so.5.34).
This is the entire stack trace of all threads:

import os
import UserDict
_abcoll.MutableMapping.register(IterableUserDict)
if issubclass(subclass, cls):
cls._abc_negative_cache.add(subclass)
self.data.add(ref(item, self._remove))

Thread 2 (Thread 0xb6b32b70 (LWP 1853)):
#0 0xb7701430 in __kernel_vsyscall ()
#1 0xb751c245 in sem_wait

GLIBC_2.1 () at …/nptl/sysdeps/unix/sysv/linux/i386/i686/…/i486/sem_wait.S:80
#2 0xb765be00 in PyThread_acquire_lock (lock=0x9148208, waitflag=1) at Python/thread_pthread.h:321
#3 0xb766044c in lock_PyThread_acquire_lock (self=0xb73715e0, args=0xb734002c) at ./Modules/threadmodule.c:52
#4 0xb75c107f in PyCFunction_Call (func=0xb6b4a56c, arg=0xb734002c, kw=0x0) at Objects/methodobject.c:116
#5 0xb762686f in call_function (f=0x8fe3094, throwflag=0) at Python/ceval.c:4021
#6 PyEval_EvalFrameEx (f=0x8fe3094, throwflag=0) at Python/ceval.c:2666
#7 0xb7628782 in PyEval_EvalCodeEx (co=0xb72fb2f0, globals=0xb72f657c, locals=0x0, args=0x8fe306c, argcount=2, kws=0x8fe3074, kwcount=0, defs=0xb7234db8, defcount=1, closure=0x0) at Python/ceval.c:3253
#8 0xb7626efb in fast_function (f=0x8fe2f2c, throwflag=0) at Python/ceval.c:4117
#9 call_function (f=0x8fe2f2c, throwflag=0) at Python/ceval.c:4042
#10 PyEval_EvalFrameEx (f=0x8fe2f2c, throwflag=0) at Python/ceval.c:2666

(…)

Thread 1 (Thread 0xb73806c0 (LWP 1807)):
#0 0xb7701430 in __kernel_vsyscall ()
#1 0xb741ee8b in waitpid () at …/sysdeps/unix/syscall-template.S:82
#2 0xb73bd863 in do_system (line=) at …/sysdeps/posix/system.c:149
#3 0xb73bdbf2 in __libc_system (line=0x901a680 “/…/v5-34-00-patches/etc/gdb-backtrace.sh 1807 1>&2”) at …/sysdeps/posix/system.c:190
#4 0xb751e27d in system (line=0x901a680 “/…/v5-34-00-patches/etc/gdb-backtrace.sh 1807 1>&2”) at pt-system.c:29
#5 0xb587754b in TUnixSystem::Exec(char const*) () from /…/v5-34-00-patches/lib/libCore.so.5.34
#6 0xb587b91e in TUnixSystem::StackTrace() () from /…/v5-34-00-patches/lib/libCore.so.5.34
#7 0xb587e417 in TUnixSystem::DispatchSignals(ESignals) () from /…/v5-34-00-patches/lib/libCore.so.5.34
#8 0xb587e52b in SigHandler(ESignals) () from /…/v5-34-00-patches/lib/libCore.so.5.34
#9 0xb5875702 in sighandler(int) () from /…/v5-34-00-patches/lib/libCore.so.5.34
#10
#11 0xb75c2de5 in PyObject_GetAttrString (v=0xb62e82cc, name=0xb62e82d4 “_1”) at Objects/object.c:1128
#12 0xb6268749 in (anonymous namespace)::LookupRootEntity(_object*, _object*) () from /…/v5-34-00-patches/lib/libPyROOT.so
#13 0xb62689cf in (anonymous namespace)::RootLookDictString(_dictobject*, _object*, long) () from /…/v5-34-00-patches/lib/libPyROOT.so
#14 0xb75bde84 in PyDict_DelItem (op=0xb6b4935c, key=0xb62e82c0) at Objects/dictobject.c:816
#15 0xb75bdfc4 in dict_ass_sub (mp=0xb6b4935c, v=0xb62e82c0, w=0x0) at Objects/dictobject.c:1184
#16 0xb75802d8 in PyObject_DelItem (o=0xb6b4935c, key=0xb62e82c0) at Objects/abstract.c:205
#17 0xb76228d8 in PyEval_EvalFrameEx (f=0x8fe3efc, throwflag=0) at Python/ceval.c:1718
#18 0xb7627eab in fast_function (f=0x91b61b4, throwflag=0) at Python/ceval.c:4107
#19 call_function (f=0x91b61b4, throwflag=0) at Python/ceval.c:4042
#20 PyEval_EvalFrameEx (f=0x91b61b4, throwflag=0) at Python/ceval.c:2666

(…)

===========================================================
#11 0xb75c2de5 in PyObject_GetAttrString (v=0xb62e82cc, name=0xb62e82d4 “_1”) at Objects/object.c:1128
#12 0xb6268749 in (anonymous namespace)::LookupRootEntity(_object*, _object*) () from /…/v5-34-00-patches/lib/libPyROOT.so
#13 0xb62689cf in (anonymous namespace)::RootLookDictString(_dictobject*, _object*, long) () from /…/v5-34-00-patches/lib/libPyROOT.so
#14 0xb75bde84 in PyDict_DelItem (op=0xb6b4935c, key=0xb62e82c0) at Objects/dictobject.c:816
#15 0xb75bdfc4 in dict_ass_sub (mp=0xb6b4935c, v=0xb62e82c0, w=0x0) at Objects/dictobject.c:1184
#16 0xb75802d8 in PyObject_DelItem (o=0xb6b4935c, key=0xb62e82c0) at Objects/abstract.c:205
#17 0xb76228d8 in PyEval_EvalFrameEx (f=0x8fe3efc, throwflag=0) at Python/ceval.c:1718
#18 0xb7627eab in fast_function (f=0x91b61b4, throwflag=0) at Python/ceval.c:4107
#19 call_function (f=0x91b61b4, throwflag=0) at Python/ceval.c:4042
#20 PyEval_EvalFrameEx (f=0x91b61b4, throwflag=0) at Python/ceval.c:2666
#21 0xb7628782 in PyEval_EvalCodeEx (co=0xb6d6cde8, globals=0xb6e6c9bc, locals=0x0, args=0x94664cc, argcount=1, kws=0x94664d0, kwcount=1, defs=0xb6bcd078, defcount=1, closure=0x0) at Python/ceval.c:3253
#22 0xb7626efb in fast_function (f=0x946638c, throwflag=0) at Python/ceval.c:4117
#23 call_function (f=0x946638c, throwflag=0) at Python/ceval.c:4042
#24 PyEval_EvalFrameEx (f=0x946638c, throwflag=0) at Python/ceval.c:2666
#25 0xb7628782 in PyEval_EvalCodeEx (co=0xb6d7bb60, globals=0xb6e6c9bc, locals=0x0, args=0xb4af22d8, argcount=1, kws=0xb7340038, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#26 0xb75aa31e in function_call (func=0xb6bcfd4c, arg=0xb4af22cc, kw=0xb62e4cec) at Objects/funcobject.c:526
#27 0xb7580cc4 in PyObject_Call (func=0xb6bcfd4c, arg=0xb4af22cc, kw=0xb62e4cec) at Objects/abstract.c:2529
#28 0xb7623ab0 in ext_do_call (f=0x91bad7c, throwflag=0) at Python/ceval.c:4334
#29 PyEval_EvalFrameEx (f=0x91bad7c, throwflag=0) at Python/ceval.c:2705
#30 0xb7628782 in PyEval_EvalCodeEx (co=0xb72f4d10, globals=0xb723ac64, locals=0x0, args=0xb7340038, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#31 0xb75aa21c in function_call (func=0xb723c87c, arg=0xb734002c, kw=0x0) at Objects/funcobject.c:526
#32 0xb7580cc4 in PyObject_Call (func=0xb723c87c, arg=0xb734002c, kw=0x0) at Objects/abstract.c:2529
#33 0xb762104b in PyEval_CallObjectWithKeywords (func=0xb723c87c, arg=0xb734002c, kw=0x0) at Python/ceval.c:3890
#34 0xb764abd8 in call_sys_exitfunc () at Python/pythonrun.c:1727
#35 Py_Finalize () at Python/pythonrun.c:413
#36 Py_Finalize () at Python/pythonrun.c:394
#37 0xb765e170 in Py_Main (argc=2, argv=0xbffb3c64) at Modules/main.c:664
#38 0x080485d7 in main (argc=2, argv=0xbffb3c64) at ./Modules/python.c:23

----------------------------------------------------------------------[/code] Note: the difference between the first and the second call is that in the second case I did not “touch” any ROOT related thing after doing “import” and before “Ctrl-D” (this problem does not appear if I try “python” instead of “ipython”).

Just a comment: This doesn’t occur if one uses a qualified import, i.e.

import ROOT

or something like

import ROOT as r

Hi,

the latter should not make a difference, b/c only when doing “import ROOT” is initialization deferred, so touching a ROOT thingy (other than gROOT, btw.) makes a difference. With “from ROOT import *” all initialization is done immediately.

That said … IPython adds a command line layer on top of the normal python interpreter loop, changing what can be done with the interpreter (IPython takes up hooks for example, w/o the ability to share).

My guess is that here, it causes the offload of the ROOT.py module before the exit of the IPython commandline object that had its dictionary modified by insertion of RootLookDictString(). With an object out of ROOT.py outstanding, there’s a reference that prevents it from offloading ROOT.py early, and it gets shutdown normally after the atexit() cleanup, and removed in the first round of module offloading.

I’ll have a look later to see whether anything can be done about it. Presumably I’ll need to add a self-reference in the C++ code to the PyROOT.so module, and remove that in the atexit() call.

Cheers,
Wim

Hi,

just installed ipython, but I have different problems with it: “from ROOT import *” is unable to modify the right dictionary and so lookups don’t work at all. Also, I can’t make gRootModule go away no matter what I try.

Anyway, I implemented a Weakref and protection for gRootModule going dodo-bird. That is proper enough as a general measure (either that, or when the lookup on the dict is set, it should take a hard reference out of principle). Is in v5-34-00-patches. Hopefully it fixes the issue you observe …

Cheers,
Wim

I’m afraid I still get the same behaviour (ROOT v5-34-00-patches@48727)

Hi,

then I have no further ideas, and without being able to reproduce it, there’s little else I can do …

Looking at the back trace with the crash being here:PyObject_GetAttrString (v=0xb62e82cc, name=0xb62e82d4 "_1")so the given string being clearly valid, I can only imagine ‘v’ (which is gRootModule) being invalid.

If you’re willing to debug, one option would be to compile python with debug support so that all reference counts are checked, another would be to run the application under valgrind (not that much fun with python, to be sure).

Cheers,
Wim

That particular line seems to be changed now (the rest of the output seems to be quite the same): =========================================================== #11 PyObject_GetAttr (v=0x8cc22cc, name=0x0) at Objects/object.c:1171 #12 0xb63c083f in _object* PyROOT::MakeRootClassFromString<PyROOT::TScopeAdapter, PyROOT::TBaseAdapter, PyROOT::TMemberAdapter>(std::string const&, _object*) () from /.../v5-34-00-patches/lib/libPyROOT.so #13 0xb63ba826 in (anonymous namespace)::LookupRootEntity(_object*, _object*) () from /.../v5-34-00-patches/lib/libPyROOT.so #14 0xb63baabf in (anonymous namespace)::RootLookDictString(_dictobject*, _object*, long) () from /.../v5-34-00-patches/lib/libPyROOT.so #15 0xb75eee84 in PyDict_DelItem (op=0x8be835c, key=0x8cc22c0) at Objects/dictobject.c:816 #16 0xb75eefc4 in dict_ass_sub (mp=0x8be835c, v=0x8cc22c0, w=0x0) at Objects/dictobject.c:1184 #17 0xb75b12d8 in PyObject_DelItem (o=0x8be835c, key=0x8cc22c0) at Objects/abstract.c:205 #18 0xb76538d8 in PyEval_EvalFrameEx (f=0x8c61074, throwflag=0) at Python/ceval.c:1718 #19 0xb7658eab in fast_function (f=0x94d3f9c, throwflag=0) at Python/ceval.c:4107 #20 call_function (f=0x94d3f9c, throwflag=0) at Python/ceval.c:4042 #21 PyEval_EvalFrameEx (f=0x94d3f9c, throwflag=0) at Python/ceval.c:2666 #22 0xb7659782 in PyEval_EvalCodeEx (co=0x89acda0, globals=0x89769bc, locals=0x0, args=0x94d4a84, argcount=1, kws=0x94d4a88, kwcount=1, defs=0x8aef098, defcount=1, closure=0x0) at Python/ceval.c:3253 #23 0xb7657efb in fast_function (f=0x94d4944, throwflag=0) at Python/ceval.c:4117 #24 call_function (f=0x94d4944, throwflag=0) at Python/ceval.c:4042 #25 PyEval_EvalFrameEx (f=0x94d4944, throwflag=0) at Python/ceval.c:2666 #26 0xb7659782 in PyEval_EvalCodeEx (co=0x89bcb18, globals=0x89769bc, locals=0x0, args=0x8eb82b8, argcount=1, kws=0xb7371038, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #27 0xb75db31e in function_call (func=0x8af1d14, arg=0x8eb82ac, kw=0x8cbecec) at Objects/funcobject.c:526 #28 0xb75b1cc4 in PyObject_Call (func=0x8af1d14, arg=0x8eb82ac, kw=0x8cbecec) at Objects/abstract.c:2529 #29 0xb7654ab0 in ext_do_call (f=0x87bf6bc, throwflag=0) at Python/ceval.c:4334 #30 PyEval_EvalFrameEx (f=0x87bf6bc, throwflag=0) at Python/ceval.c:2705 #31 0xb7659782 in PyEval_EvalCodeEx (co=0xb7325cc8, globals=0xb726bc64, locals=0x0, args=0xb7371038, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #32 0xb75db21c in function_call (func=0xb726d844, arg=0xb737102c, kw=0x0) at Objects/funcobject.c:526 #33 0xb75b1cc4 in PyObject_Call (func=0xb726d844, arg=0xb737102c, kw=0x0) at Objects/abstract.c:2529 #34 0xb765204b in PyEval_CallObjectWithKeywords (func=0xb726d844, arg=0xb737102c, kw=0x0) at Python/ceval.c:3890 #35 0xb767bbd8 in call_sys_exitfunc () at Python/pythonrun.c:1727 #36 Py_Finalize () at Python/pythonrun.c:413 #37 Py_Finalize () at Python/pythonrun.c:394 #38 0xb768f170 in Py_Main (argc=2, argv=0xbfbb4a84) at Modules/main.c:664 #39 0x080485d7 in main (argc=2, argv=0xbfbb4a84) at ./Modules/python.c:23 ===========================================================

Hi,

ah, so maybe it did work. The PyObject_GetAttrString() is protected with a predicate on gRootModule, but the next calls are not. I figured they’d be fine since they look in caches, but creating ROOT objects when shutting down is pretty pointless. Rather, the lookup function should just give up right away if !gRootModule.

Could you update from SVN and try again?

Thanks,
Wim

I’m afraid we are back at “PyObject_GetAttrString”: =========================================================== #11 0xb7696de5 in PyObject_GetAttrString (v=0x9e7e2cc, name=0x9e7e2d4 "_1") at Objects/object.c:1128 #12 0xb64ba823 in (anonymous namespace)::LookupRootEntity(_object*, _object*) () from /.../v5-34-00-patches/lib/libPyROOT.so #13 0xb64baadf in (anonymous namespace)::RootLookDictString(_dictobject*, _object*, long) () from /.../v5-34-00-patches/lib/libPyROOT.so #14 0xb7691e84 in PyDict_DelItem (op=0x9daf35c, key=0x9e7e2c0) at Objects/dictobject.c:816 #15 0xb7691fc4 in dict_ass_sub (mp=0x9daf35c, v=0x9e7e2c0, w=0x0) at Objects/dictobject.c:1184 #16 0xb76542d8 in PyObject_DelItem (o=0x9daf35c, key=0x9e7e2c0) at Objects/abstract.c:205 #17 0xb76f68d8 in PyEval_EvalFrameEx (f=0x9ff7db4, throwflag=0) at Python/ceval.c:1718 #18 0xb76fbeab in fast_function (f=0x9eab304, throwflag=0) at Python/ceval.c:4107 #19 call_function (f=0x9eab304, throwflag=0) at Python/ceval.c:4042 #20 PyEval_EvalFrameEx (f=0x9eab304, throwflag=0) at Python/ceval.c:2666 #21 0xb76fc782 in PyEval_EvalCodeEx (co=0x9b73da0, globals=0x9b3d9bc, locals=0x0, args=0xa68eac4, argcount=1, kws=0xa68eac8, kwcount=1, defs=0x9cb6098, defcount=1, closure=0x0) at Python/ceval.c:3253 #22 0xb76faefb in fast_function (f=0xa68e984, throwflag=0) at Python/ceval.c:4117 #23 call_function (f=0xa68e984, throwflag=0) at Python/ceval.c:4042 #24 PyEval_EvalFrameEx (f=0xa68e984, throwflag=0) at Python/ceval.c:2666 #25 0xb76fc782 in PyEval_EvalCodeEx (co=0x9b83b18, globals=0x9b3d9bc, locals=0x0, args=0xa074318, argcount=1, kws=0xb7414038, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #26 0xb767e31e in function_call (func=0x9cb8d14, arg=0xa07430c, kw=0x9e7acec) at Objects/funcobject.c:526 #27 0xb7654cc4 in PyObject_Call (func=0x9cb8d14, arg=0xa07430c, kw=0x9e7acec) at Objects/abstract.c:2529 #28 0xb76f7ab0 in ext_do_call (f=0x99866bc, throwflag=0) at Python/ceval.c:4334 #29 PyEval_EvalFrameEx (f=0x99866bc, throwflag=0) at Python/ceval.c:2705 #30 0xb76fc782 in PyEval_EvalCodeEx (co=0xb73c8cc8, globals=0xb730ec64, locals=0x0, args=0xb7414038, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #31 0xb767e21c in function_call (func=0xb7310844, arg=0xb741402c, kw=0x0) at Objects/funcobject.c:526 #32 0xb7654cc4 in PyObject_Call (func=0xb7310844, arg=0xb741402c, kw=0x0) at Objects/abstract.c:2529 #33 0xb76f504b in PyEval_CallObjectWithKeywords (func=0xb7310844, arg=0xb741402c, kw=0x0) at Python/ceval.c:3890 #34 0xb771ebd8 in call_sys_exitfunc () at Python/pythonrun.c:1727 #35 Py_Finalize () at Python/pythonrun.c:413 #36 Py_Finalize () at Python/pythonrun.c:394 #37 0xb7732170 in Py_Main (argc=2, argv=0xbfd1c264) at Modules/main.c:664 #38 0x080485d7 in main (argc=2, argv=0xbfd1c264) at ./Modules/python.c:23 ===========================================================

Hi,

is it consistent between the two stack traces or random?

Maybe in one more attempt to reproduce, which version of python and ipython are you running?

Cheers,
Wim

Well, I’ve tried it three times now and all three outputs are the same (except for some 0x12345678 values, of course).

I’m using:

Python 2.7.3 (default, Feb 24 2013, 00:11:10) / "[GCC 4.6.3] on linux2"
IPython 0.13.1 – An enhanced Interactive Python.

In my first post here, I have forgotten to add that I use:

gcc version 4.6.3 (Target: i686-pc-linux-gnu / Thread model: posix)

Hi,

sorry, missed that you already wrote that in your first posting (too many balls in the air, and too little sleep). Anyway, yes with 0.13.1 I see the crash, too.

So much easier to work, if something can be reproduced. :slight_smile:

Fixed now. The reason that the weakref solution did not work, is that it’s not legal to take weak references to module objects. Now, ROOT.py explicitly calls to reset gRootModule (whose ref-count was indeed zero) in the atexit handler, and the lazy lookup checks for gRootModule being non-zero.

Cheers,
Wim

=D>