PyQt application crashes on exit after drawing PyROOT data

ROOT
1

Dear ROOT experts.

I have the following problem. I’m working on a data analysis application which uses PyROOT for histogram/graph plotting. The application is written in Python and has a GUI written in PyQt4.9 I use it on the lxplus cluster so it uses the newest version of ROOT.

When I start it and exit immediately nothing wrong happens.
But when I draw even a single histogram, close it and then close the application I get the following segmentation listed below.

The problem only occurs during remote sessions (ssh -XY) it doesn’t show up during vnc sessions.

Any ideas what’s going on?
I will try to create a minimum code example later.

PS I don’t delete any object or deal with destructors. I leave it purely to the garbage collector.

*** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:

#0 0x00002b6a6a90ee2f in waitpid () from /lib64/libc.so.6
#1 0x00002b6a6a8b2491 in do_system () from /lib64/libc.so.6
#2 0x00002b6a6a8b27e7 in system () from /lib64/libc.so.6
#3 0x00002b6a7a506a96 in TUnixSystem::StackTrace() ()
from /afs/cern.ch/sw/lcg/app/releases/ROOT/5.32.02/x86_64-slc5-gcc43-opt/root/lib/libCore.so
#4 0x00002b6a7a50636c in TUnixSystem::DispatchSignals(ESignals) ()
from /afs/cern.ch/sw/lcg/app/releases/ROOT/5.32.02/x86_64-slc5-gcc43-opt/root/lib/libCore.so
#5
#6 0x00002b6a69fd7d10 in pthread_mutex_lock () from /lib64/libpthread.so.0
#7 0x00002b6a6fcc6f23 in XrmDestroyDatabase () from /usr/lib64/libX11.so.6
#8 0x00002b6a6fcae942 in _XFreeDisplayStructure ()
from /usr/lib64/libX11.so.6
#9 0x00002b6a6fc99c5b in XCloseDisplay () from /usr/lib64/libX11.so.6
#10 0x00002b6a71f638d5 in ?? ()
from /afs/cern.ch/sw/lcg/external/qt/4.6.3.p1/x86_64-slc5-gcc43-opt/lib/libQtGui.so.4
#11 0x00002b6a71ef133e in QApplication::~QApplication() ()
from /afs/cern.ch/sw/lcg/external/qt/4.6.3.p1/x86_64-slc5-gcc43-opt/lib/libQtGui.so.4
#12 0x00002b6a718b099b in ?? ()
from /afs/cern.ch/sw/lcg/external/pygraphics/1.1p1_python2.6/x86_64-slc5-gcc43-opt/lib/python2.6/site-packages/PyQt4/QtGui.so
#13 0x00002b6a718b0307 in ?? ()
from /afs/cern.ch/sw/lcg/external/pygraphics/1.1p1_python2.6/x86_64-slc5-gcc43-opt/lib/python2.6/site-packages/PyQt4/QtGui.so
#14 0x00002b6a7116b739 in PyDict_New ()
at /build/vdiez/Python-2.6.5p2/Objects/dictobject.c:224
#15 0x00000000004646c5 in subtype_dealloc (self=0x1c965c88)
at /build/vdiez/Python-2.6.5p2/Objects/typeobject.c:1019
#16 0x0000000000445557 in insertdict (mp=0x1c562850, key=0x2b6a6e215660,
hash=8358283631056071551, value=0x750cf0)
at /build/vdiez/Python-2.6.5p2/Objects/dictobject.c:459
#17 0x0000000000447800 in PyDict_SetItem (op=0x1c562850, key=0x2b6a6e215660,
value=0x750cf0) at /build/vdiez/Python-2.6.5p2/Objects/dictobject.c:701
#18 0x000000000044970f in _PyModule_Clear (m=)
at /build/vdiez/Python-2.6.5p2/Objects/moduleobject.c:138
#19 0x00000000004aa68b in PyImport_Cleanup ()
at /build/vdiez/Python-2.6.5p2/Python/import.c:441
#20 0x00000000004b669b in Py_Finalize ()
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:438
#21 0x00000000004b6808 in Py_Exit (sts=3014656)
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:1744
#22 0x00000000004b693e in handle_system_exit ()
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:1120
#23 0x00000000004b6b6d in PyErr_PrintEx (set_sys_last_vars=1)
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:1130
#24 0x00000000004b818c in PyRun_SimpleFileExFlags (fp=0x7ffffe33ea0c,
filename=0x7ffffe33ea0c “./VeloDBView”, closeit=1, flags=0x7ffffe33d2d0)
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:939
#25 0x000000000041506b in Py_Main (argc=3, argv=0x7ffffe33d3f8)
at /build/vdiez/Python-2.6.5p2/Modules/main.c:572
#26 0x00002b6a6a893994 in __libc_start_main () from /lib64/libc.so.6
#27 0x00000000004141d9 in _start ()

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.

#6 0x00002b6a69fd7d10 in pthread_mutex_lock () from /lib64/libpthread.so.0
#7 0x00002b6a6fcc6f23 in XrmDestroyDatabase () from /usr/lib64/libX11.so.6
#8 0x00002b6a6fcae942 in _XFreeDisplayStructure ()
from /usr/lib64/libX11.so.6
#9 0x00002b6a6fc99c5b in XCloseDisplay () from /usr/lib64/libX11.so.6
#10 0x00002b6a71f638d5 in ?? ()
from /afs/cern.ch/sw/lcg/external/qt/4.6.3.p1/x86_64-slc5-gcc43-opt/lib/libQtGui.so.4
#11 0x00002b6a71ef133e in QApplication::~QApplication() ()
from /afs/cern.ch/sw/lcg/external/qt/4.6.3.p1/x86_64-slc5-gcc43-opt/lib/libQtGui.so.4
#12 0x00002b6a718b099b in ?? ()
from /afs/cern.ch/sw/lcg/external/pygraphics/1.1p1_python2.6/x86_64-slc5-gcc43-opt/lib/python2.6/site-packages/PyQt4/QtGui.so
#13 0x00002b6a718b0307 in ?? ()
from /afs/cern.ch/sw/lcg/external/pygraphics/1.1p1_python2.6/x86_64-slc5-gcc43-opt/lib/python2.6/site-packages/PyQt4/QtGui.so
#14 0x00002b6a7116b739 in PyDict_New ()
at /build/vdiez/Python-2.6.5p2/Objects/dictobject.c:224
#15 0x00000000004646c5 in subtype_dealloc (self=0x1c965c88)
at /build/vdiez/Python-2.6.5p2/Objects/typeobject.c:1019
#16 0x0000000000445557 in insertdict (mp=0x1c562850, key=0x2b6a6e215660,
hash=8358283631056071551, value=0x750cf0)
at /build/vdiez/Python-2.6.5p2/Objects/dictobject.c:459
#17 0x0000000000447800 in PyDict_SetItem (op=0x1c562850, key=0x2b6a6e215660,
value=0x750cf0) at /build/vdiez/Python-2.6.5p2/Objects/dictobject.c:701
#18 0x000000000044970f in _PyModule_Clear (m=)
at /build/vdiez/Python-2.6.5p2/Objects/moduleobject.c:138
#19 0x00000000004aa68b in PyImport_Cleanup ()
at /build/vdiez/Python-2.6.5p2/Python/import.c:441
#20 0x00000000004b669b in Py_Finalize ()
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:438
#21 0x00000000004b6808 in Py_Exit (sts=3014656)
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:1744
#22 0x00000000004b693e in handle_system_exit ()
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:1120
#23 0x00000000004b6b6d in PyErr_PrintEx (set_sys_last_vars=1)
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:1130
#24 0x00000000004b818c in PyRun_SimpleFileExFlags (fp=0x7ffffe33ea0c,
filename=0x7ffffe33ea0c “./VeloDBView”, closeit=1, flags=0x7ffffe33d2d0)
at /build/vdiez/Python-2.6.5p2/Python/pythonrun.c:939
#25 0x000000000041506b in Py_Main (argc=3, argv=0x7ffffe33d3f8)
at /build/vdiez/Python-2.6.5p2/Modules/main.c:572
#26 0x00002b6a6a893994 in __libc_start_main () from /lib64/libc.so.6
#27 0x00000000004141d9 in _start ()

2

Hi,

from the looks of it, this problem isn’t related to python, but purely an interaction problem between some of the used C++ libs. Did you set ROOT up to use Qt?

Cheers,
Wim

3

Hi Wim.

Thanks for your respond. I’ll add some more details.

My application uses PyQt “application” approach:

browser = QtGui.QApplication(sys.argv) myapp = Browser() myapp.show() sys.exit(browser.exec_())

Later in the code I create standard PyROOT histograms and the GraphObjects are being hold by PyQt windows (this is a simplified example):

[code]import ROOT

class GraphObject(object):
def init(self):
ROOT.gROOT.Reset()

    self.canv1 = ROOT.TCanvas(setHashName(self, "canv"), 'Velo DBView', 200, 10, 800, 600)
    self.canv1.SetGridx()
    self.canv1.SetGridy()
    ROOT.SetOwnership(self.canv1, False)
   (...)

   self.graph = ROOT.TGraph(len(X), X, Y)
   self.graph.SetTitle(setGraphTitle(self.job))
   self.graph.Draw("AP")
   ROOT.SetOwnership(self.graph, False)
   canv1.Update()[/code]

Do I need to use some special approach when dealing with PyQt and PyROOT?

ADDED:
I went through qtexample.py in tutorials/pyroot and apart from not being able to run it…

Traceback (most recent call last): File "/afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.00/x86_64-slc5-gcc43-opt/root/tutorials/pyroot/qtexample.py", line 50, in <module> QObject.connect(application, SIGNAL("lastWindowClosed()"),termAddress ,SLOT("Terminate()")) RuntimeError: underlying C/C++ object has been deleted
… I figured out that my application has completely different architecture than the example.

What I want to achieve is to have a main application written in PyQt which shows separate non-qt ROOT canvases. Is this achievable without using gApplication?

Cheers,
Michal

4

Michal,

what I meant was, did you mod rootrc to load QtROOT, see: http://root.bnl.gov/QtRoot/root/root.diff/config/unix.rootrc?

I’m not sure what it means to “PyQt which shows separate non-qt ROOT canvases”. Mixing both Qt and non-Qt windows will mean that you’ll have to drive GUI events yourself. That’s perfectly possible, yet I’d think you’re better off using QtROOT, which allows for a single event loop.

As for the example, what that RuntimeError means is precisely that: on the C++ side, the QObject was deleted. I don’t know why that happens, but I do know that I get the same if I mix Qt and non-Qt. By putting the above referenced .rootrc in $HOME, however, all works fine.

Cheers,
Wim

5

Hi Wim.

I will try your solution in a moment. However I have an additional question.

What should I do to make this rootrc visible on LXPLUS?
Of course I don’t have access to the main root catalog where rootrc should be put.
Can I create some special environment variable which would point to that file?

I write my application not only for myself, but also for other users and I need to be able to just load it somehow during either setting up the environment for the project, or during initialization of my application.

6

Hi,

haven’t tried, but according to the User’s Manual, page 29, the first .rootrc considered is the one in the current directory. Presumably that allows its installation next to the application (and worst case, you could first use os.chdir, then load ROOT, then os.chdir back to ensure the local directory when starting ROOT).

HTH,
Wim