root6: Seg fault immediately upon opening root6

[jfcaron3]

Hi all, I was having trouble compiling ROOT6 manually, and as I have MacPorts installed for other libs, I decided to try ROOT6 from MacPorts. It actually compiles without errors, but as soon as I open it (i.e. I type in "root" and press enter), I get a seg fault:

 *** Break *** segmentation violation
 Generating stack trace...
 0x0000000105b7e962 in TROOT::LoadClass(char const*, char const*, bool) (in libCore.6.so) + 194
 0x0000000105b7b960 in TROOT::TROOT(char const*, char const*, void (**)()) (in libCore.6.so) + 4848
 0x0000000105b79ed9 in ROOT::GetROOT1() (in libCore.6.so) + 89
 0x0000000105b8077b in _GLOBAL__I_a (in libCore.6.so) + 27
 0x00007fff6c355c2e in <unknown function>
 0x00007fff6c355dba in <unknown function>
 0x00007fff6c352a62 in <unknown function>
 0x00007fff6c3529eb in <unknown function>
 0x00007fff6c3528f6 in <unknown function>

The splash screen comes up and stays up, then it goes away if I click on it. I am on OSX 10.9.2. I DO have another version of root (5.34) in a directory, but it's not "installed" in any system folders, it lives entirely in a folder in ~/Software.

The details of my previous compilation issues are here: ​http://root.cern.ch/phpBB3/viewtopic.php?f=3&t=18143&p=77299#p77299 including the seg fault printout. I tried installing the +debug variant and running it in lldb, but the process ends with error 139 and I can't do a "backtrace" command.

As suggested in the other root6 ticket, I tried checking to see if all the provided object and binary files were pointing to the right locations. Here's how I did it:

for abin in `port contents root6|grep 'bin'`; do otool -L $abin|grep -v '/opt/local/.*'|grep -v '/usr/lib/.*'|grep -v '/System/Library/,*'; done
for aso in `port contents root6|grep '.*\.so'`; do otool -L $aso|grep -v '/opt/local/.*'|grep -v '/usr/lib/.*'|grep -v '/System/Library/,*'; done

Both commands printed nothing, meaning that when I run otool -L on all *.so and .*bin.* files, all the returned locations are in one of: /opt/local, /usr/lib, or /System/Library.

Extra info, output of clang -v:

clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

[mojca (Mojca Miklavec)]

Honestly I don't know where to start looking, but if Chris has no idea either, I would suggest you to ask on the macports-dev mailing list or on the irc channel with a reference to this ticket. The only other thing that comes to my mind would be attaching main.log from the build (that means running port destroot root6 as the previous log was probably deleted already), but I don't know if anything useful/obvious could be seen from there.

I assume that you have all the ports up-to-date, that you used default variants in root6 (including cocoa) and that you didn't try to manually switch the compiler to build some of dependencies? Did you change variants to any of the dependencies that could be relevant for this? (But no, I have no clue where to start looking at all.)

[cjones051073 (Chris Jones)]

Are you using the binary installation of root6, or did you build it from source yourself. If the binary installation, please try forcing a private build (so run 'sudo port -s install root6'). If that fails, post the build log.

Chris

[cjones051073 (Chris Jones)]

Another thought. Do you have any private root startup items ? Such as anything run from ~/.rootrc ?

When I first starting running root6 I had to update my startup items, as I was running a script from from ~/.rootrc file, that was doing things that did not work with root6... In theory you could be getting a crash from this.

Chris

[jfcaron3]

Replying to jonesc@…:

Another thought. Do you have any private root startup items ? Such as anything run from ~/.rootrc ?

Well, that fixed it. As far as I know, I am not running any special startup items from ~/.rootrc, but moving it to old.rootrc allowed ROOT6 to open. I will see if this also resolves my problems compiling my own ROOT6.

I still think it is a problem in ROOT that an old .rootrc file can cause such a mysterious seg fault...

[jfcaron3]

Replying to jfcaron@…:

Replying to jonesc@…:

Another thought. Do you have any private root startup items ? Such as anything run from ~/.rootrc ?

Well, that fixed it. As far as I know, I am not running any special startup items from ~/.rootrc, but moving it to old.rootrc allowed ROOT6 to open. I will see if this also resolves my problems compiling my own ROOT6.

I still think it is a problem in ROOT that an old .rootrc file can cause such a mysterious seg fault...

By the way, I now tried commenting out line-by-line my rootrc file to see which one causes the problem, it's this one: Unix.*.Root.UseThreads: true

[mojca (Mojca Miklavec)]

Great. Not great that it crashes, but it's great that you diagnosed and isolated it. I can reproduce the problem here.

[mojca (Mojca Miklavec)]

> root6

 *** Break *** segmentation violation



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

Thread 1 (process 85261):
#0  0x00007fff832a5168 in wait4 ()
#1  0x00007fff840ff5f5 in system ()
#2  0x000000010d67b471 in TUnixSystem::StackTrace ()
#3  0x000000010d67e799 in TUnixSystem::DispatchSignals ()
#4  <signal handler called>
#5  0x000000010d5c4bbc in TSystem::GetLibraries ()
#6  0x000000010d5c39ed in TSystem::Load ()
#7  0x000000010d5a5162 in TROOT::LoadClass ()
#8  0x000000010d5a1e83 in TROOT::TROOT ()
#9  0x000000010d5a03a9 in ROOT::GetROOT1 ()
#10 0x000000010d5a709b in global constructors keyed to a ()
#11 0x00007fff6d0f0da6 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#12 0x00007fff6d0f0af2 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#13 0x00007fff6d0ee2e4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#14 0x00007fff6d0ee27d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#15 0x00007fff6d0ef0b7 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#16 0x00007fff6d0e44dd in __dyld__ZN4dyld24initializeMainExecutableEv ()
#17 0x00007fff6d0e860b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#18 0x00007fff6d0e2059 in __dyld__dyld_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
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  0x000000010d5c4bbc in TSystem::GetLibraries ()
#6  0x000000010d5c39ed in TSystem::Load ()
#7  0x000000010d5a5162 in TROOT::LoadClass ()
#8  0x000000010d5a1e83 in TROOT::TROOT ()
#9  0x000000010d5a03a9 in ROOT::GetROOT1 ()
#10 0x000000010d5a709b in global constructors keyed to a ()
#11 0x00007fff6d0f0da6 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#12 0x00007fff6d0f0af2 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#13 0x00007fff6d0ee2e4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#14 0x00007fff6d0ee27d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#15 0x00007fff6d0ef0b7 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#16 0x00007fff6d0e44dd in __dyld__ZN4dyld24initializeMainExecutableEv ()
#17 0x00007fff6d0e860b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#18 0x00007fff6d0e2059 in __dyld__dyld_start ()
===========================================================

[cjones051073 (Chris Jones)]

Can you, if you haven't already, feed back this to the ROOT forum where you first mentioned the problem. Not only to let upstream know about the problem, but also to clear MacPorts name ;)

cheers Chris

[mojca (Mojca Miklavec)]

Thank you for posting on the forum.

I would still suggest to open a ticket in their bug tracker on JIRA. (You should mention that you are using a Mac, but please try to avoid mentioning MacPorts in the ticket if possible.)

Chris, can one run port test with ROOT somehow?

[jfcaron3]

I've reported the problem here: ​https://sft.its.cern.ch/jira/browse/ROOT-6379

Jean-François

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Thank you for posting on the forum.

I would still suggest to open a ticket in their bug tracker on JIRA. (You should mention that you are using a Mac, but please try to avoid mentioning MacPorts in the ticket if possible.)

Chris, can one run port test with ROOT somehow?

Testing... never thought about that. Thing is ROOT has many very different facets, so there isn't really one way to test 'ROOT'. If I want to test something, I normally see if there is something under the tutorials area ('/opt/local/libexec/root6/share/doc/root/tutorials' for the root6 port) that does it ...

[lpsinger (Leo Singer)]

Replying to mojca@…:

(You should mention that you are using a Mac, but please try to avoid mentioning MacPorts in the ticket if possible.)

Why? Do they have their own preferred binary distribution, or something? I think that most upstream developers are if anything more responsive and helpful if you mention that you are working on porting or distributing their projects for a larger audience.

[cjones051073 (Chris Jones)]

My experience is different, which is the knee jerk reaction of upstream when reporting a problem with something that is a 'secondary' packaging by some secondary source, to first just blame that packaging.. We have certainly suffered from this a fair bit in the past with MacPorts and ROOT, which means MacPorts might have an undeserved bad name with the ROOT devs. This is why if I report a problem to them now I first make sure it is not related to MP, by reproducing it in a standalone build, and then just reporting that. Sometimes the problem is because the MP build is using a newer external than ROOT expects (FreeType...) but at least we have removed from the equation the MP build of ROOT itself...

Chris

[mojca (Mojca Miklavec)]

I take part of the blame. In the process of trying to get root6 working on MacPorts (when CMake support was still in its infacy), I probably opened more than 10 tickets, mentioning MacPorts in every single one of them. More as a hint (like it always helps to mention the OS version and compiler).

(I understand that developers of any given software would be annoyed if an unresponsive maintainer starts packaging the software, introducing lots of problems just by wrongly packaging, but this wasn't the case here.)

Just like some developers would say "stop using windows, windows are buggy", (some of) root developers apparently saw "bug" and "macports" next to each other so often that they started making unjustified causal links between the two and started advising me against using MacPorts despite the great majority of issues were real issues in ROOT. But something that other users wouldn't ever stumble upon, even if just because they didn't have the latest version of some library like MacPorts did. Or because they would never use the same combination of configuration options.

[lpsinger (Leo Singer)]

Replying to jonesc@…:

My experience is different, which is the knee jerk reaction of upstream when reporting a problem with something that is a 'secondary' packaging by some secondary source, to first just blame that packaging.. We have certainly suffered from this a fair bit in the past with MacPorts and ROOT, which means MacPorts might have an undeserved bad name with the ROOT devs. This is why if I report a problem to them now I first make sure it is not related to MP, by reproducing it in a standalone build, and then just reporting that. Sometimes the problem is because the MP build is using a newer external than ROOT expects (FreeType...) but at least we have removed from the equation the MP build of ROOT itself...

Ah, that's a shame. But you're doing the right thing by determining the broadest possible platform scope of a bug before reporting it.

[mojca (Mojca Miklavec)]

Can you please try the attached patch? (Upstream patch, see ​ticket and ​patch.)

If that works as expected, it will automatically work properly in the next version, but I leave it up to Chris to decide whether to patch it now or to wait for the next release.

[mojca (Mojca Miklavec)]

I guess this was fixed automatically with the first upgrade to a newer version (whenever that was), so I'm closing the ticket.