Cout causes bus error

I am running into some strange behavior in version 5.20.00 on my Mac, when I load a library I created called libTFFT.
This library is nothing special except that it links into libfftw.dylib using:
g++ -O2 -dynamiclib -single_module -undefined dynamic_lookup -install_name libTFFT.dylib obj/Darwin/TFFTCorrelation.o -o libTFFT.dylib -L/usr/local/lib -llibfftw

When the library is loaded into root, I get strange behavior with calls to cout or cerr. The extreme example is the following bus error (see output below), even though nothing from this library is called.

If I DO NOT have the “-L/usr/local/lib -llibfftw” in the link command, but instead load this library into root “by hand” with: .L /usr/local/lib/
(I need to make a link from the libfftw3.dylib to for this to work)
then I do not get any crashes and all behaves well.

This seems rather strange and appears to be some linking issues inside root.
Anyone have an idea? I would much prefer the libraries to be properly linked with their dependencies.


---------------------------- Output -----------------------------------------

dhcp-062:Root> root
  *                                         *
  *        W E L C O M E  to  R O O T       *
  *                                         *
  *   Version   5.20/00      24 June 2008   *
  *                                         *
  *  You are welcome to visit our Web site  *
  *            *
  *                                         *

ROOT 5.20/00 (trunk@24524, Jun 25 2008, 10:06:00 on macosx)

CINT/ROOT C/C++ Interpreter version 5.16.29, Jan 08, 2008
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
Root Logon from HOME --- Welcome. 
Helpers loaded
Local Directory Root Logon. 
slib/Darwin/ loaded. 
Local Directory Root Logon. 
slib/Darwin/ loaded. 
root [0] cout << "Hello\n";                                      
root [1] TFile tmp("Hello.root","RECREATE");                     
root [2]                           
TFile**		Hello.root	
 TFile*		Hello.root	
root [3] double X[1000],Y[1000];                                 
root [4] for(int i=0;i<1000;i++){ X[i]=(i/100.);Y[i]=sin(X[i]);};
root [5] TGraph *F=new TGraph(1000,X,Y)                          
root [6] cout << "Hello\n";                                      
root [7] F->Draw("AL")                                           
<TCanvas::MakeDefCanvas>: created default TCanvas with name c1
root [8] cout << "Hello\n";            
root [9]                                                
TFile**		Hello.root	
 TFile*		Hello.root	
root [10] F->Write()                                              
root [11] cout << "Hello\n";
root [12]          
TFile**		Hello.root	
 TFile*		Hello.root	

 *** Break *** bus error
  KEY: TGraph	Graph;/Users/maurik/Documents/GravWav/Analysis/Root/1853: No such file or directory.
Attaching to process 1853.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ...................................................................................... done
0x91595f69 in wait4 ()

========== STACKS OF ALL THREADS ==========

Thread 1 (process 1853 thread 0x10b):
#0  0x91595f69 in wait4 ()
#1  0x91593abc in system$UNIX2003 ()
#2  0x0086e371 in TUnixSystem::StackTrace ()
#3  0x008716c5 in TUnixSystem::DispatchSignals ()
#4  0x00871838 in SigHandler ()
#5  <signal handler called>
#6  0x022061f9 in std::codecvt<char, char, __mbstate_t>::do_unshift (this=0x22a20a8, __to=0xa03dd500 "?=?", __to_next=@0x20) at ../../../../gcc-4.2.2/libstdc++-v3/src/
#7  0x93663664 in std::ostream::operator<< ()
#8  0x016acca0 in TKey::ls ()
#9  0x0168bd5d in TDirectoryFile::ls ()
#10 0x016912d7 in TFile::ls ()
#11 0x009856b8 in G__G__Base2_10_0_42 ()
#12 0x00f653e2 in Cint::G__ExceptionWrapper ()
#13 0x01030813 in G__execute_call ()
#14 0x0103738d in G__call_cppfunc ()
#15 0x0100bb5e in G__interpret_func ()
#16 0x00ff6f6b in G__getfunction ()
#17 0x011084fb in G__getstructmem ()
#18 0x010fe322 in G__getvariable ()
#19 0x00fc3d31 in G__getitem ()
#20 0x00fc6ca9 in G__getexpr ()
#21 0x01071c21 in G__exec_statement ()
#22 0x00fad9bf in G__exec_tempfile_core ()
#23 0x00fadd67 in G__exec_tempfile_fp ()
#24 0x01079a11 in G__process_cmd ()
#25 0x00859cf4 in TCint::ProcessLine ()
#26 0x007addf7 in TApplication::ProcessLine ()
#27 0x0002fe46 in TRint::HandleTermInput ()
#28 0x0002f4e0 in TTermInputHandler::Notify ()
#29 0x00031444 in TTermInputHandler::ReadNotify ()
#30 0x008719d0 in TUnixSystem::CheckDescriptors ()
#31 0x008720fb in TUnixSystem::DispatchOneEvent ()
#32 0x007fdc80 in TSystem::InnerLoop ()
#33 0x0080041b in TSystem::Run ()
#34 0x007aca43 in TApplication::Run ()
#35 0x0003073e in TRint::Run ()
#36 0x00001bae in main ()

Which version of MacOS are you running on (I don’t think v5.20 work on Darwin and your libfftw library seems to the Darwin library).


Hello Phillipe,

Thank you much for your reply.

I am using Mac OS X 10.5.5 (Intel) This seems to be compatible with Root version 5.20.00, as there is a binary provided in the download section. I am using the 3.1.2 version of the FFTW3 library.

What I cannot figure out is that the problem (a crash of root when using cout) only happens when I load a library into root that is created with a linking command that includes the external library.
I discovered that if I do not link with the libfftw3.dylib but instead load it manually into root before my own library, I do not get the crash. This forms a work-around that is usable but not elegant, especially since everyone who wants to use the code will have to make link to the library to give is a .so extension. (Is there a deeper reason for the problem of loading libraries with the .dylib extension?)

Unfortunately, I don’t even know how to start debugging the cause of this problem, some interference with these libraries.


in ROOT we also use libfftw3 in the libFFTW library. But we link libfftw3 statically from libfftw3.a. Loading libFFTW I cannot reproduce your problem. Could you try linking your TFFT lib statically with libfftw3 to see if the problem persists.

Your plugin lib needs to have the extension .so as the MacOS dlopen() does not accept the .dylib extension (beyond ROOT’s control). Actually since MacOS X 10.5 you can always use .so, no need anymore to build .dylibs, as the linker now also allows linking agains .so’s instead of only .dylibs.

Cheers, Fons.

Thank you.

Linking statically DOES indeed work and the crash goes away. This is a huge improvement.

I checked out the root trunk from SVN, and modified TUnixSystem.cxx and loadsystem.cxx (in cint), which is sufficient to allow the loading of .dylib files on Mac OS X 10.5. I cannot test this with 10.4 right now though.

Should I send these modifications somewhere?


Hi Maurik,

no we don’t want to support the loading of files with dylib extension. They were never supposed to be dynamically loaded, and now in 10.5 Apple has made it such that .dylibs are not needed at all anymore, so please move just to .so’s only, like we do for ROOT on 10.5 and Unix/Linux has been doing already for ages.

Cheers, Fons.