Segmentation fault during build under OSX 10.5.5

Hi I’m trying to build ROOT version 20.00 on Mac OSX Leaopard 10.5.5. The build fails when trying to create a dictionary:

[quote]Generating dictionary core/base/src/G__Base1.cxx…
core/utils/src/rootcint_tmp -cint -f core/base/src/G__Base1.cxx -c core/base/inc/TApplication.h core/base/inc/TApplicationImp.h core/base/inc/TAtt3D.h core/base/inc/TAttAxis.h core/base/inc/TAttBBox.h core/base/inc/TAttFill.h core/base/inc/TAttLine.h core/base/inc/TAttMarker.h core/base/inc/TAttPad.h core/base/inc/TAttText.h core/base/inc/TBenchmark.h core/base/inc/TBrowser.h core/base/inc/TBrowserImp.h core/base/inc/TBuffer.h core/base/inc/TBuffer3D.h core/base/inc/TBuffer3DTypes.h core/base/inc/TCanvasImp.h core/base/inc/TColor.h core/base/inc/TContextMenu.h core/base/inc/TContextMenuImp.h core/base/inc/TControlBarImp.h core/base/inc/TDatime.h core/base/inc/TDirectory.h core/base/inc/TEnv.h core/base/inc/TError.h core/base/inc/TException.h core/base/inc/TExec.h core/base/inc/TFolder.h core/base/inc/TGuiFactory.h core/base/inc/TInspectorImp.h core/base/inc/TMD5.h core/base/inc/TMacro.h core/base/inc/TMathBase.h core/base/inc/TMemberInspector.h core/base/inc/TMessageHandler.h core/base/inc/TNamed.h core/base/inc/TObjString.h core/base/inc/TObject.h core/base/inc/TPRegexp.h core/base/inc/TPluginManager.h core/base/inc/TPoint.h core/base/inc/TProcessID.h core/base/inc/TProcessUUID.h core/base/inc/TQClass.h core/base/inc/TQCommand.h core/base/inc/TQConnection.h core/base/inc/TQObject.h core/base/inc/TROOT.h core/base/inc/TRef.h core/base/inc/TRefCnt.h core/base/inc/TRegexp.h core/base/inc/TRemoteObject.h core/base/inc/TRootIOCtor.h core/base/inc/TStopwatch.h core/base/inc/TStorage.h core/base/inc/TString.h core/base/inc/TStringLong.h core/base/inc/TStyle.h core/base/inc/TSysEvtHandler.h core/base/inc/TSystem.h core/base/inc/TSystemDirectory.h core/base/inc/TSystemFile.h core/base/inc/TTask.h core/base/inc/TTime.h core/base/inc/TTimer.h core/base/inc/TUUID.h core/base/inc/TVersionCheck.h core/base/inc/TVirtualFFT.h core/base/inc/TVirtualFitter.h core/base/inc/TVirtualGL.h core/base/inc/TVirtualPS.h core/base/inc/TVirtualPad.h core/base/inc/TVirtualPadEditor.h core/base/inc/TVirtualViewer3D.h core/base/inc/LinkDef1.h
make: *** [core/base/src/G__Base1.cxx] Segmentation fault
rm core/utils/src/RStl_tmp.cxx core/utils/src/rootcint_tmp.cxx
[/quote]

Has anyone seen something like this before? If so, how did you get ROOT to build. I just used the default configuration i.e. ./configure with no additions.

Cheers,

Hugh

No, we have never seen this problem. Note that what you get is a compiler crash and not a compilation error. What is your compiler version?

Rene

I’m using gcc 4.0.1. Here’s the output of gcc -v:

[quote]Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
[/quote]

I managed to get ROOT 20.00 to compile by setting the target architecture as macosx instead of macosx64. This is really weird because the previous version of ROOT compiled fine using macosx64. I thought that I might have a faulty RAM module, but I’ve spent the whole of today running memtest and everything seems fine.

I know you say that the problem is a compiler crash, and of course know much more than me about these things, but I note that the crash happens when make is running rootcint. Has anything in rootcint changed since the last release that might explain this behaviour?

I also tried with several newer versions of gcc but still no success with the 64 bit version!

Hi,

could you just try the svn trunk version of ROOT. I use it all the time on MacPro and MacBook in 64bit version. The compiler should not matter so much but I am using the latest Xcode with gcc version 4.0.1 (Apple Inc. build 5488).

Let me know the result.

Cheers, Fons.

No change I’m afraid. Exactly the same error. Now using the svn trunk version of ROOT and XCode tools 3.1.1. Now gcc -v gives:

[quote]Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5488)
[/quote]

The 32 bit version seems to be working fine though. I guess this might be a very subtle memory problem that memtest was unable to discover. Any other ideas would be much appreciated.

Cheers,

Hugh

What Mac are you actually running on?

Cheers, Fons.

It’s an iMac Core Duo 2.8GHz with 3GB RAM.

Hi,

I also have an iMac 24" 2.8 and 4GB with 10.5.5 and cannot reproduce this problem. The svn trunk compiles in macosx64 bit mode to the end and the program runs fine. Puzzled. Do you have an other 64-bit mac to try it on?

Cheers, Fons.

Unfortunately I don’t have another machine to test it on. Just to check, all you do is:

[quote]./configure
make[/quote]

and it works fine? If that’s the case, then this is most likely a hardware problem, would you agree?

Hugh

Yep,

./configure
make

could you lift some memory modules?

Cheers, Fons.

I wasn’t able to replace any memory modules, but I did try swapping them between the two slots, the logic being that if there was a problem in one of the physical registers, then swapping the modules would change the memory address which corresponded to the bad module and the crash, if it occurred, would not happen in the same place.

The result? Exactly the same failure at exactly the same point in the compilation! I read some articles on the web that suggested gcc sometimes runs out of swapfile space and this can cause a seg fault, but since you can get it to compile fine, I must admit that possibility seems unlikely. This problem is just weird!

Hugh

The problem is indeed weird as I don’t see it on MBP 64-bit, iMac 64-bit and MacPro 64-bit. All 10.5.5 with 4 to 8 GB RAM.

Does it happen in debug mode too, try:

./configure --build=debug
make

Cheers, Fons.

Could the problem be that I only have 3GB of RAM which is being exhausted in 64 bit mode and not in 32 bit mode?

No, plain ROOT and especially rootcint run in very little memory.

Cheers, Fons.

Doesn’t compile in debug mode either. Never mind, the 32 bit version is fine. Will advise if I ever get it working!

Hi, I know it’s been a while and this problem still hasn’t resolved with subsequent releases of ROOT. Perhaps the following information will give some clues as to what’s going on. As the sementation fault didn’t give a stack trace I used gdb to try and see what was going on:

[quote]$ gdb --args core/utils/src/rootcint_tmp -cint -f core/base/src/G__Base1.cxx -c core/base/inc/TApplication.h core/base/inc/TApplicationImp.h core/base/inc/TAtt3D.h core/base/inc/TAttAxis.h core/base/inc/TAttBBox.h core/base/inc/TAttFill.h core/base/inc/TAttLine.h core/base/inc/TAttMarker.h core/base/inc/TAttPad.h core/base/inc/TAttText.h core/base/inc/TBenchmark.h core/base/inc/TBrowser.h core/base/inc/TBrowserImp.h core/base/inc/TBuffer.h core/base/inc/TBuffer3D.h core/base/inc/TBuffer3DTypes.h core/base/inc/TCanvasImp.h core/base/inc/TColor.h core/base/inc/TContextMenu.h core/base/inc/TContextMenuImp.h core/base/inc/TControlBarImp.h core/base/inc/TDatime.h core/base/inc/TDirectory.h core/base/inc/TEnv.h core/base/inc/TError.h core/base/inc/TException.h core/base/inc/TExec.h core/base/inc/TFolder.h core/base/inc/TGuiFactory.h core/base/inc/TInspectorImp.h core/base/inc/TMD5.h core/base/inc/TMacro.h core/base/inc/TMathBase.h core/base/inc/TMemberInspector.h core/base/inc/TMessageHandler.h core/base/inc/TNamed.h core/base/inc/TObjString.h core/base/inc/TObject.h core/base/inc/TPRegexp.h core/base/inc/TPluginManager.h core/base/inc/TPoint.h core/base/inc/TProcessID.h core/base/inc/TProcessUUID.h core/base/inc/TQClass.h core/base/inc/TQCommand.h core/base/inc/TQConnection.h core/base/inc/TQObject.h core/base/inc/TROOT.h core/base/inc/TRef.h core/base/inc/TRefCnt.h core/base/inc/TRegexp.h core/base/inc/TRemoteObject.h core/base/inc/TRootIOCtor.h core/base/inc/TStopwatch.h core/base/inc/TStorage.h core/base/inc/TString.h core/base/inc/TStringLong.h core/base/inc/TStyle.h core/base/inc/TSysEvtHandler.h core/base/inc/TSystem.h core/base/inc/TSystemDirectory.h core/base/inc/TSystemFile.h core/base/inc/TTask.h core/base/inc/TTime.h core/base/inc/TTimer.h core/base/inc/TUUID.h core/base/inc/TVersionCheck.h core/base/inc/TVirtualFFT.h core/base/inc/TVirtualGL.h core/base/inc/TVirtualPS.h core/base/inc/TVirtualPad.h core/base/inc/TVirtualPadEditor.h core/base/inc/TVirtualViewer3D.h core/base/inc/LinkDef1.h
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i386-apple-darwin”…Reading symbols for shared libraries … done

(gdb) run
Starting program: /Applications/Scientific/ROOT/root/core/utils/src/rootcint_tmp -cint -f core/base/src/G__Base1.cxx -c core/base/inc/TApplication.h core/base/inc/TApplicationImp.h core/base/inc/TAtt3D.h core/base/inc/TAttAxis.h core/base/inc/TAttBBox.h core/base/inc/TAttFill.h core/base/inc/TAttLine.h core/base/inc/TAttMarker.h core/base/inc/TAttPad.h core/base/inc/TAttText.h core/base/inc/TBenchmark.h core/base/inc/TBrowser.h core/base/inc/TBrowserImp.h core/base/inc/TBuffer.h core/base/inc/TBuffer3D.h core/base/inc/TBuffer3DTypes.h core/base/inc/TCanvasImp.h core/base/inc/TColor.h core/base/inc/TContextMenu.h core/base/inc/TContextMenuImp.h core/base/inc/TControlBarImp.h core/base/inc/TDatime.h core/base/inc/TDirectory.h core/base/inc/TEnv.h core/base/inc/TError.h core/base/inc/TException.h core/base/inc/TExec.h core/base/inc/TFolder.h core/base/inc/TGuiFactory.h core/base/inc/TInspectorImp.h core/base/inc/TMD5.h core/base/inc/TMacro.h core/base/inc/TMathBase.h core/base/inc/TMemberInspector.h core/base/inc/TMessageHandler.h core/base/inc/TNamed.h core/base/inc/TObjString.h core/base/inc/TObject.h core/base/inc/TPRegexp.h core/base/inc/TPluginManager.h core/base/inc/TPoint.h core/base/inc/TProcessID.h core/base/inc/TProcessUUID.h core/base/inc/TQClass.h core/base/inc/TQCommand.h core/base/inc/TQConnection.h core/base/inc/TQObject.h core/base/inc/TROOT.h core/base/inc/TRef.h core/base/inc/TRefCnt.h core/base/inc/TRegexp.h core/base/inc/TRemoteObject.h core/base/inc/TRootIOCtor.h core/base/inc/TStopwatch.h core/base/inc/TStorage.h core/base/inc/TString.h core/base/inc/TStringLong.h core/base/inc/TStyle.h core/base/inc/TSysEvtHandler.h core/base/inc/TSystem.h core/base/inc/TSystemDirectory.h core/base/inc/TSystemFile.h core/base/inc/TTask.h core/base/inc/TTime.h core/base/inc/TTimer.h core/base/inc/TUUID.h core/base/inc/TVersionCheck.h core/base/inc/TVirtualFFT.h core/base/inc/TVirtualGL.h core/base/inc/TVirtualPS.h core/base/inc/TVirtualPad.h core/base/inc/TVirtualPadEditor.h core/base/inc/TVirtualViewer3D.h core/base/inc/LinkDef1.h
warning: posix_spawn failed, trying execvp, error: 86

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x0000000100b2d1c1 in ?? ()
[/quote]
I’m afraid that this means nothing to me, perhaps the “posix_spawn” warning suggests a solution to somebody?

Cheers,

Hugh

Okay, a bit more digging and I’ve discovered the following:

Both EXC_BAD_ACCESS and signal 13 (EACCES) refer to memory access errors.

Most bizarre of all though is that the cause of this attempt to access the unavailable memory appears to be linked to the number of command line arguments. Using gdb as above and then doing:

(which if I’m understanding correctly prints the place in the source corresponding to where the error happened) gives:

4231 } 4232 } 4233 4234 } 4235 4236 4237 //______________________________________________________________________________ 4238 int main(int argc, char **argv) 4239 { 4240 if (argc < 2) {
(This is actually in the file rootcint.cxx, which gets copied to rootcint_tmp.cxx before being compiled into rootcint_tmp during the build process, but is then deleted. In order to let gdb find the place in the source I repeated what the build system does manually and copied rootcint.cxx to rootcint_tmp.cxx, I assume that they’re the same files because trying all the examples below with bin/rootcint gives the same results as using core/utils/src/rootcint_tmp). The only pointer in the above segment of code is argv, indicating that this may be the problem. I’m guessing a single integer wouldn’t cause an issue like this?

Anyway, i tried to test this by removing some of the command line arguments from the rootcint_tmp command and it seems that the critical number is 40 arguments. What’s more the length of the arguments don’t seem to matter for example, the result of:

is of course an error:

but crucially, not a crash, whereas:

results in a segmentation fault. This is not a command line length issue because:

[quote]$ core/utils/src/rootcint_tmp -cint -f core/base/src/G__Base1.cxx -c core/base/inc/TApplication.h core/base/inc/TApplicationImp.h core/base/inc/TAtt3D.h core/base/inc/TAttAxis.h core/base/inc/TAttBBox.h core/base/inc/TAttFill.h core/base/inc/TAttLine.h core/base/inc/TAttMarker.h core/base/inc/TAttPad.h core/base/inc/TAttText.h core/base/inc/TBenchmark.h core/base/inc/TBrowser.h core/base/inc/TBrowserImp.h core/base/inc/TBuffer.h core/base/inc/TBuffer3D.h core/base/inc/TBuffer3DTypes.h core/base/inc/TCanvasImp.h core/base/inc/TColor.h core/base/inc/TContextMenu.h core/base/inc/TContextMenuImp.h core/base/inc/TControlBarImp.h core/base/inc/TDatime.h core/base/inc/TDirectory.h core/base/inc/TEnv.h core/base/inc/TError.h core/base/inc/TException.h core/base/inc/TExec.h core/base/inc/TFolder.h core/base/inc/TGuiFactory.h core/base/inc/TInspectorImp.h core/base/inc/TMD5.h core/base/inc/TMacro.h core/base/inc/TMathBase.h core/base/inc/TMemberInspector.h spurious/but/nonetheless/outrageously/long/and/complicated/argument core/base/inc/LinkDef1.h
[/quote]
Throws the expected error:

[quote]Error: cannot open file “spurious/but/nonetheless/outrageously/long/and/complicated/argument” :0:
!!!Removing core/base/src/G__Base1.cxx core/base/src/G__Base1.h !!!
Error: core/utils/src/rootcint_tmp: error loading headers…
[/quote]
To illustrate that this works even for non-invented filenames:

[quote]$ core/utils/src/rootcint_tmp -cint -f core/base/src/G__Base1.cxx -c core/base/inc/TApplication.h core/base/inc/TApplicationImp.h core/base/inc/TAtt3D.h core/base/inc/TAttAxis.h core/base/inc/TAttBBox.h core/base/inc/TAttFill.h core/base/inc/TAttLine.h core/base/inc/TAttMarker.h core/base/inc/TAttPad.h core/base/inc/TAttText.h core/base/inc/TBenchmark.h core/base/inc/TBrowser.h core/base/inc/TBrowserImp.h core/base/inc/TBuffer.h core/base/inc/TBuffer3D.h core/base/inc/TBuffer3DTypes.h core/base/inc/TCanvasImp.h core/base/inc/TColor.h core/base/inc/TContextMenu.h core/base/inc/TContextMenuImp.h core/base/inc/TControlBarImp.h core/base/inc/TDatime.h core/base/inc/TDirectory.h core/base/inc/TEnv.h core/base/inc/TError.h core/base/inc/TException.h core/base/inc/TExec.h core/base/inc/TFolder.h core/base/inc/TGuiFactory.h core/base/inc/TInspectorImp.h core/base/inc/TMD5.h core/base/inc/TMacro.h core/base/inc/TMathBase.h core/base/inc/TMemberInspector.h core/base/inc/TMessageHandler.h core/base/inc/LinkDef1.h

Error: link requested for unknown class TFileHandler core/base/inc/LinkDef1.h:148:
Error: link requested for unknown class TStyle core/base/inc/LinkDef1.h:150:
Error: link requested for unknown class TVirtualX core/base/inc/LinkDef1.h:151:
Error: link requested for unknown class TVirtualViewer3D core/base/inc/LinkDef1.h:154:
Error: link requested for unknown class TGLManager core/base/inc/LinkDef1.h:156:
Error: link requested for unknown class TVirtualGLPainter core/base/inc/LinkDef1.h:157:
Error: link requested for unknown class TVirtualGLManip core/base/inc/LinkDef1.h:158:
Error: link requested for unknown class TVirtualPS core/base/inc/LinkDef1.h:159:
Error: link requested for unknown class TGLPaintDevice core/base/inc/LinkDef1.h:160:
Error: link requested for unknown class TVirtualPadEditor core/base/inc/LinkDef1.h:162:
Error: link requested for unknown class TVirtualFFT core/base/inc/LinkDef1.h:164:
Warning: Error occurred during reading source files
Note: Link requested for undefined class TVirtualPad (ignore this message) :0:
Warning: Error occurred during dictionary source generation
!!!Removing core/base/src/G__Base1.cxx core/base/src/G__Base1.h !!!
Error: core/utils/src/rootcint_tmp: error loading headers…

$ core/utils/src/rootcint_tmp -cint -f core/base/src/G__Base1.cxx -c core/base/inc/TApplication.h core/base/inc/TApplicationImp.h core/base/inc/TAtt3D.h core/base/inc/TAttAxis.h core/base/inc/TAttBBox.h core/base/inc/TAttFill.h core/base/inc/TAttLine.h core/base/inc/TAttMarker.h core/base/inc/TAttPad.h core/base/inc/TAttText.h core/base/inc/TBenchmark.h core/base/inc/TBrowser.h core/base/inc/TBrowserImp.h core/base/inc/TBuffer.h core/base/inc/TBuffer3D.h core/base/inc/TBuffer3DTypes.h core/base/inc/TCanvasImp.h core/base/inc/TColor.h core/base/inc/TContextMenu.h core/base/inc/TContextMenuImp.h core/base/inc/TControlBarImp.h core/base/inc/TDatime.h core/base/inc/TDirectory.h core/base/inc/TEnv.h core/base/inc/TError.h core/base/inc/TException.h core/base/inc/TExec.h core/base/inc/TFolder.h core/base/inc/TGuiFactory.h core/base/inc/TInspectorImp.h core/base/inc/TMD5.h core/base/inc/TMacro.h core/base/inc/TMathBase.h core/base/inc/TMemberInspector.h core/base/inc/TMessageHandler.h core/base/inc/TNamed.h core/base/inc/LinkDef1.h

Segmentation fault
[/quote]
I may be misinterpreting what’s going on but it does seem like for 64 bit compilation under OSX 10.5.7 (and apparently only on my mac), having too many command line arguments is crashing rootcint. Does anybody have any suggestions as to why this might be happening, is there some system variable that I’ve inadvertently modified?

Any help appreciated,

Cheers,

Hugh

Hi,

In the trunk, a few weeks ago, we lifted a hard coded limitation on the command line length in rootcint. So if you did not already do so, please try with the trunk.

Cheers,
Philippe.

Same error I’m afraid. Also, if it was a hard-coded limitation, I would have expected it to affect all machines equally, whereas from the previous discussions it appears that my machine is a unique example. Also I didn’t think you’d have limited the command line argument number to 40 and then given more than 40 arguments in your own build system!

Cheers,

Hugh