Draw() crash on MacOSX

Hello Rooters,

I have problems with any drawing commands. Simple use of Draw() to a TH1F leads to a segfault. Unfortunately, I can not decipher where the problem originates. Other X applications work fine (e.g. Inkscape) and the same version of root runs fine on another Mac box and another Linux box.

Here is my setup: MacOSX 10.6.4 with MacPorts. I tried current trunk (rev:35563) and roostats branch (rev:35307). I also tried recompiling after a “make clean” and “make distclean” (Is there a cleaner clean than this?). I cannot exactly retrace when the problem first occurred, but I might have updated my macports.

This is my problem:
root [0] t1 = new TH1F(“test”,“test”, 100,0,10)
(class TH1F*)0x102a02dc0
root [1] t1->Draw()

*** Break *** segmentation violation

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

Thread 1 (process 80360):
#0 0x00007fff87439c90 in wait4 ()
#1 0x00007fff8744e23e in system ()
#2 0x0000000100113995 in TUnixSystem::StackTrace ()
#3 0x000000010011131a in TUnixSystem::DispatchSignals ()
#4
#5 0x0000000103a30005 in _XReply ()
#6 0x0000000103a0bda7 in XAllocColor ()
#7 0x0000000103cc5ce3 in find_useable_visual ()
#8 0x0000000103cc6392 in query_screen_visual_id ()
#9 0x0000000103cc7bab in create_asvisual_for_id ()
#10 0x0000000103c51812 in TASImage::InitVisual ()
#11 0x0000000103c5b023 in TASImage::ReadImage ()
#12 0x0000000102ce2e03 in TImage::Open ()
#13 0x00000001030f386b in TGPicturePool::GetPicture ()
#14 0x00000001031b23fd in TGHScrollBar::TGHScrollBar ()
#15 0x000000010312c072 in TGCanvas::TGCanvas ()
#16 0x0000000103209694 in TRootCanvas::CreateCanvas ()
#17 0x0000000103209dfa in TRootCanvas::TRootCanvas ()
#18 0x00000001032127d7 in TRootGuiFactory::CreateCanvasImp ()
#19 0x0000000102e8b8e5 in TCanvas::Constructor ()
#20 0x0000000102e8bd83 in TCanvas::TCanvas ()
#21 0x0000000102e8cdba in TCanvas::MakeDefCanvas ()
#22 0x0000000102eddcdc in G__G__GPad_147_0_122 ()
#23 0x000000010091f256 in Cint::G__ExceptionWrapper ()
#24 0x00000001009d8fac in G__execute_call ()
#25 0x00000001009df67b in G__call_cppfunc ()
#26 0x00000001009b886a in G__interpret_func ()
#27 0x00000001009a1751 in G__getfunction ()
#28 0x0000000100975a3a in G__getitem ()
#29 0x000000010097a167 in G__getexpr ()
#30 0x0000000100a0ca9e in G__exec_statement ()
#31 0x00000001009613f6 in G__exec_tempfile_core ()
#32 0x0000000100961706 in G__exec_tempfile_fp ()
#33 0x0000000100a165b4 in G__process_cmd ()
#34 0x000000010001eeee in TCint::ProcessLine ()
#35 0x000000010006f4cb in TApplication::ProcessLine ()
#36 0x000000010009d781 in TROOT::ProcessLine ()
#37 0x000000010008f164 in TObject::AppendPad ()
#38 0x00000001025175b3 in TH1::Draw ()
#39 0x000000010028fc78 in G__G__Base2_11_0_15 ()
#40 0x000000010091f256 in Cint::G__ExceptionWrapper ()
#41 0x00000001009d8fac in G__execute_call ()
#42 0x00000001009df67b in G__call_cppfunc ()
#43 0x00000001009b886a in G__interpret_func ()
#44 0x00000001009a1751 in G__getfunction ()
#45 0x0000000100a971e0 in G__getstructmem ()
#46 0x0000000100a8d7cf in G__getvariable ()
#47 0x0000000100975339 in G__getitem ()
#48 0x000000010097a167 in G__getexpr ()
#49 0x0000000100a0ca9e in G__exec_statement ()
#50 0x00000001009613f6 in G__exec_tempfile_core ()
#51 0x0000000100961706 in G__exec_tempfile_fp ()
#52 0x0000000100a165b4 in G__process_cmd ()
#53 0x000000010001eeee in TCint::ProcessLine ()
#54 0x000000010006f4cb in TApplication::ProcessLine ()
#55 0x00000001012f7ebf in TRint::HandleTermInput ()
#56 0x00000001012f6497 in TTermInputHandler::Notify ()
#57 0x00000001012f83bd in TTermInputHandler::ReadNotify ()
#58 0x0000000100110fe2 in TUnixSystem::CheckDescriptors ()
#59 0x00000001001114e5 in TUnixSystem::DispatchOneEvent ()
#60 0x00000001000ab85d in TSystem::InnerLoop ()
#61 0x00000001000ad863 in TSystem::Run ()
#62 0x000000010006db37 in TApplication::Run ()
#63 0x00000001012f70fb in TRint::Run ()
#64 0x00000001000019a0 in main ()

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.

#5 0x0000000103a30005 in _XReply ()
#6 0x0000000103a0bda7 in XAllocColor ()
#7 0x0000000103cc5ce3 in find_useable_visual ()
#8 0x0000000103cc6392 in query_screen_visual_id ()
#9 0x0000000103cc7bab in create_asvisual_for_id ()
#10 0x0000000103c51812 in TASImage::InitVisual ()
#11 0x0000000103c5b023 in TASImage::ReadImage ()
#12 0x0000000102ce2e03 in TImage::Open ()
#13 0x00000001030f386b in TGPicturePool::GetPicture ()
#14 0x00000001031b23fd in TGHScrollBar::TGHScrollBar ()
#15 0x000000010312c072 in TGCanvas::TGCanvas ()
#16 0x0000000103209694 in TRootCanvas::CreateCanvas ()
#17 0x0000000103209dfa in TRootCanvas::TRootCanvas ()
#18 0x00000001032127d7 in TRootGuiFactory::CreateCanvasImp ()
#19 0x0000000102e8b8e5 in TCanvas::Constructor ()
#20 0x0000000102e8bd83 in TCanvas::TCanvas ()
#21 0x0000000102e8cdba in TCanvas::MakeDefCanvas ()

Any help would be great on this one.
Cheers

Replying to myself: Uninstalling all xorg* packages in MacPorts and also the xpm package and then doing a distclean, configure, make solved the problem for now; but that broke almost all my macports software in the process.

I do not see the problem on my Mac. But I do not use MacPorts.

Doh! I just started seeing the same thing. Problem appears on two machines now, both OS X 10.6.4, one with ROOT 5.27/05 (built from SVN) and one with ROOT 5.27/07 (just built from scratch to see if that helped). One recent change on both machines was the installation of emacs from MacPorts, which (among others) also built xorg-libXmu, xorg-libXaw and xpm.

The problem is that anything trying to access X11 will segfault the same way. Creating a TBrowser, a TCanvas, etc. Typical stack trace below.

Will try to investigate…

Jeroen

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

Thread 1 (process 55937):
#0  0x00007fff83bc3c90 in wait4 ()
#1  0x00007fff83bd823e in system ()
#2  0x000000010010c395 in TUnixSystem::StackTrace ()
#3  0x000000010010a431 in TUnixSystem::DispatchSignals ()
#4  <signal handler called>
#5  0x0000000103744015 in _XReply ()
#6  0x000000010371fdb7 in XAllocColor ()
#7  0x0000000103a58453 in find_useable_visual ()
#8  0x0000000103a58b02 in query_screen_visual_id ()
#9  0x0000000103a5a31b in create_asvisual_for_id ()
#10 0x0000000103a1c9a2 in TASImage::InitVisual ()
#11 0x0000000103a26bd3 in TASImage::ReadImage ()
#12 0x0000000102a62f83 in TImage::Open ()
#13 0x0000000102e2304b in TGPicturePool::GetPicture ()
#14 0x0000000102ee469d in TGHScrollBar::TGHScrollBar ()
#15 0x0000000102e5c062 in TGCanvas::TGCanvas ()
#16 0x0000000102f3cf24 in TRootCanvas::CreateCanvas ()
#17 0x0000000102f3d68a in TRootCanvas::TRootCanvas ()
#18 0x0000000102f46147 in TRootGuiFactory::CreateCanvasImp ()
#19 0x0000000101709365 in TCanvas::Constructor ()
#20 0x0000000101709bdc in TCanvas::TCanvas ()
#21 0x000000010177a232 in G__G__GPad_148_0_10 ()
#22 0x0000000100860cd6 in Cint::G__ExceptionWrapper ()
#23 0x000000010091b15c in G__execute_call ()
#24 0x0000000100921fdb in G__call_cppfunc ()
#25 0x00000001008f8533 in G__interpret_func ()
#26 0x00000001008e63ad in G__getfunction ()
#27 0x00000001008adcea in G__define_var ()
#28 0x000000010094b933 in G__exec_statement ()
#29 0x00000001008a3c1d in G__exec_tempfile_core ()
#30 0x00000001008a3f36 in G__exec_tempfile_fp ()
#31 0x0000000100959141 in G__process_cmd ()
#32 0x000000010001f7be in TCint::ProcessLine ()
#33 0x0000000100065f9b in TApplication::ProcessLine ()
#34 0x00000001011c980f in TRint::HandleTermInput ()
#35 0x00000001011c7de7 in TTermInputHandler::Notify ()
#36 0x00000001011c9d0d in TTermInputHandler::ReadNotify ()
#37 0x000000010010a0f2 in TUnixSystem::CheckDescriptors ()
#38 0x000000010010ab65 in TUnixSystem::DispatchOneEvent ()
#39 0x00000001000a2fad in TSystem::InnerLoop ()
#40 0x00000001000a5bc3 in TSystem::Run ()
#41 0x00000001000647a7 in TApplication::Run ()
#42 0x00000001011c8a4b in TRint::Run ()
#43 0x00000001000019a0 in main ()
===========================================================


The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://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.
===========================================================
#5  0x0000000103744015 in _XReply ()
#6  0x000000010371fdb7 in XAllocColor ()
#7  0x0000000103a58453 in find_useable_visual ()
#8  0x0000000103a58b02 in query_screen_visual_id ()
#9  0x0000000103a5a31b in create_asvisual_for_id ()
#10 0x0000000103a1c9a2 in TASImage::InitVisual ()
#11 0x0000000103a26bd3 in TASImage::ReadImage ()
#12 0x0000000102a62f83 in TImage::Open ()
#13 0x0000000102e2304b in TGPicturePool::GetPicture ()
#14 0x0000000102ee469d in TGHScrollBar::TGHScrollBar ()
#15 0x0000000102e5c062 in TGCanvas::TGCanvas ()
#16 0x0000000102f3cf24 in TRootCanvas::CreateCanvas ()
#17 0x0000000102f3d68a in TRootCanvas::TRootCanvas ()
#18 0x0000000102f46147 in TRootGuiFactory::CreateCanvasImp ()
#19 0x0000000101709365 in TCanvas::Constructor ()
#20 0x0000000101709bdc in TCanvas::TCanvas ()
===========================================================

This is already weird. For some reason my clean build of ROOT (make distclean; make) was built against two different xpm libs:

libASImage.so
        /opt/local/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
libASImageGui.so
        /opt/local/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
libFTGL.so
        /opt/local/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
libGLEW.so
        /opt/local/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
libGX11.so
        /usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
libGX11TTF.so
        /opt/local/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
libX3d.so
        /usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)

Just relinking the /opt/local ones to /usr/X11 does not help. I tried a rebuild after deactivating xpm from MacPorts but that does not help either. Looking a bit further, also libX11 is linked to in two different (this time really different) versions:

libASImage.so
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
libASImageGui.so
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
libEve.so
        /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)
libFTGL.so
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
libGLEW.so
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
libGX11.so
        /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)
libGX11TTF.so
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
libRGL.so
        /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)
libX3d.so
        /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)

This corresponds to the output of make, so somewhere the Makefiles pick up some X11-related libs from two different places. What I don’t understand at all is that config.log shows yet another location for e.g., libX11: Found file /usr/X11R6/lib/libX11.dylib.

Jeroen

Hmmm, for the moment the work-around seems to be to specify explicitly where ROOT should find all X11-related libs (i.e., take them from the MacPorts area, since I also still want to use emacs :wink:):

./configure --with-x11-libdir=/opt/local/lib/ --with-xpm-libdir=/opt/local/lib/ --with-xft-libdir=/opt/local/lib/  --with-xext-libdir=/opt/local/lib/

After some more digging I do understand why config.log shows a different location for some libs than the one used in the Makefiles. Apart from that, am I wrong in concluding that somewhere there’s a feature in one or more Makefiles that leads to ROOT incorrectly being linked against two different sets of X11 libs? (Where the segfault is just due to incompatible versions being mixed.)

Cheers,
Jeroen

I encountered the same problem after migrating from Fink to MacPorts. Jeroen’s trick also worked on my Mac, but I would suggest you all to add one more option. This is needed when you draw OpenGL objects.

I got the following error.

[code]===========================================================
#5 0x00000001069c12bb in _X11TransWritev ()
#6 0x00000001069b9aef in _XSend ()
#7 0x00000001069aec56 in XQueryExtension ()
#8 0x00000001069a4281 in XInitExtension ()
#9 0x0000000103ff5f1e in XextAddDisplay ()
#10 0x0000000106acda5d in __glXInitialize ()
#11 0x0000000106ace6e5 in GetGLXPrivScreenConfig ()
#12 0x0000000106acf54f in glXChooseVisual ()
#13 0x0000000106674e75 in TGLWidget::CreateWindow ()
#14 0x0000000106675245 in TGLWidget::Create ()
#15 0x000000010663f7d5 in TGLSAViewer::CreateGLWidget ()
#16 0x0000000106640b67 in TGLSAViewer::TGLSAViewer ()

[/code]

Thanks for the update. I’m still hoping for a real fix in the Makefiles. Will see if I can find some time…

Jeroen

Hi,

we don’t plan to support alternative X11 libraries on MacOS X, be it either from Fink, or MacPorts. We just cannot invest the effort to cross-check this matrix of build options. However, if you come up with a patch for ./configure that works for both Fink and MacPorts I’ll be happy to introduce the patch. As a first step have a look in ./configure where we check for the X11 and OpenGL libs and try putting:

 ${finkdir:+$finkdir/lib/mysql}

as fist in the list of directories to search. Of course replace in each instance “/lib/mysql” of the example above by the correct location of the X11 lib.

Cheers, Fons.

Hi,
I am seeing this same crash for any Xwindow activity, on my Mac. What is odd is that it cropped up
from one root session to another, ie. from one minute to the next, with no concurrent changes in my libraries.
I tried recompiling root, but this made no change.

I did update some of my macports libraries about an hour before this error started, which is the only connection to the problems mentioned above.
My questions are:  
  1. why should the presence of macport X libraries affect root, which is linked to the /usr/X11R6 version of those libraries??

  2. any hint as to which macports libraries I should delete to get root to work again?

thanks,
Aaron

Folks,
Following the advice in the previous messages, I also got root to work again by linking to the x libraries
from macports. So, nevermind.

Aaron

Hi,

My experience with this “issue” is very much different. Basically v5-26-00e works without a hitch using

but v5-28-00 crashed with the X-related stack trace. After reading this thread, I configured v5-28-00 with

and now TH1::Draw has not crashed (I have not tried GL, though).

So: as far as I can tell it is not an X11 setup problem, but rather something changed in the configure.in between v5-26-00e and v5-28-00 which broke the Mac OS X out of the boxness for those of us with MacPorts.

Cheers,

Andre

I’ve made a change in ./configure in the trunk to consistently look the Fink or MacPort libs before local libs. Please let me know if that solves the issues.

The change in behaviour is due to the fact that in the configure of 5.28 we now explicitly use the system version of libraries like libpng, etc instead of compiling an included version from source. This might cause problems if the system finds these libs from MacPorts which then require libX11 from MacPorts too while we take the system versions for these libs. Hopefully it is more consistent now. As I’ve no X11 from MacPorts I did not deeply test and need your feedback.

Cheers, Fons.

Any hope to build ROOT against the OS X native graphical library? Any porting?
I remember that QtROOT maybe work. And Qt is cross-platform. It seems that ROOT has an abstract GUI layer.
If ROOT supports the native graphical library of OS X, it might be a great news.

Yes, I fully agree that it would be a great thing to have. To get it native on MacOS X we would need a port of TVirtualX to Quartz/OpenGL. Currently we are investigating different options that would allow the GUI to be fully OpenGL based so that possible it can also cover mobile iOS and Android devices. Stay tuned.

Cheers, Fons.