ROOT 03.10.02 in RedHat Enterprise Linux WS Rel. 3

Hi Folks,

I recently installed ROOT version 03.10.02 on a dual Xeon machine running RedHat Enterprise Linux WS version 3. I tried two methods: precompiled and locally compiled. Both flavors led to the same problem.

I start root,


and load the library:


and then try to print some text (or do anything, really). i.e.

cout << “Hi There!” << endl;

and the result is a segmentation violation that appears to emanate from the libPhysics library. I’ve put the stack trace at the bottom of this message. If I don’t load, ROOT behaves fine. However, I need this library in my day-to-day work so I have to understand this.

(1) Does anybody else see this?
(2) Do those wiser than I understand what the stack trace is trying to tell me?


*** Break *** segmentation violation
Generating stack trace…
0xb5fbc945 in from /cern/root/pro//lib/
0xb6f5175a in G__call_cppfunc + 0x263 from /cern/root/pro//lib/
0xb6f41505 in G__interpret_func + 0x6d7 from /cern/root/pro//lib/
0xb6f29afb in G__getfunction + 0x1295 from /cern/root/pro//lib/
0xb6f3f03e in G__convert_param + 0x351 from /cern/root/pro//lib/
0xb6f40e0a in G__overload_match + 0x494 from /cern/root/pro//lib/
0xb6f41051 in G__interpret_func + 0x223 from /cern/root/pro//lib/
0xb6f2a163 in G__getfunction + 0x18fd from /cern/root/pro//lib/
0xb6f63fc3 in G__overloadopr + 0x81b from /cern/root/pro//lib/
0xb6f60ef6 in G__bstore + 0x45 from /cern/root/pro//lib/
0xb6f2023a in G__getexpr + 0x7205 from /cern/root/pro//lib/
0xb6f29711 in G__getfunction + 0xeab from /cern/root/pro//lib/
0xb6f63fc3 in G__overloadopr + 0x81b from /cern/root/pro//lib/
0xb6f60ef6 in G__bstore + 0x45 from /cern/root/pro//lib/
0xb6f1c28a in G__getexpr + 0x3255 from /cern/root/pro//lib/
0xb6f6bd7d in G__exec_statement + 0x1c23 from /cern/root/pro//lib/
0xb6f0a0ab in G__exec_tempfile_core + 0x2ce from /cern/root/pro//lib/
0xb6f0a288 in G__exec_tempfile_fp + 0x22 from /cern/root/pro//lib/
0xb6f740b2 in G__process_cmd + 0x43f9 from /cern/root/pro//lib/
0xb7207247 in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) + 0x9b from /cern/root/pro//lib/
0xb718d955 in TApplication::ProcessLine(char const*, bool, int*) + 0x577 from /cern/root/pro//lib/
0xb68bae36 in TRint::HandleTermInput() + 0x1b2 from /cern/root/pro//lib/
0xb68b9d68 in TTermInputHandler::Notify() + 0x24 from /cern/root/pro//lib/
0xb68bb5f0 in TTermInputHandler::ReadNotify() + 0x12 from /cern/root/pro//lib/
0xb726715f in TUnixSystem::CheckDescriptors() + 0xed from /cern/root/pro//lib/
0xb7266930 in TUnixSystem::DispatchOneEvent(bool) + 0x10a from /cern/root/pro//lib/
0xb71da3d5 in TSystem::InnerLoop() + 0x1b from /cern/root/pro//lib/
0xb71da36e in TSystem::Run() + 0x78 from /cern/root/pro//lib/
0xb718e39f in TApplication::Run(bool) + 0x2d from /cern/root/pro//lib/
0xb68ba962 in TRint::Run(bool) + 0x2e4 from /cern/root/pro//lib/
0x080488d5 in main + 0x71 from /cern/root/pro//bin/root.exe
0xb6689748 in __libc_start_main + 0xf8 from /lib/tls/
0x080487d5 in _Unwind_Resume + 0x31 from /cern/root/pro//bin/root.exe

Hi Folks,

Sorry for the false alarm. The stack trace I posted concerning the “problem” with libPhysics in ROOT 03.10.02 (on a RHEL 3 machine) was a red herring. It turns out that cout (i.e. iostream) is the problem. That is a problem which is NOT for this forum. :slight_smile: