Hi Rene and Philippe, I tried your hint with the debugger and the trace mode and here it is what I think the problem is: In my program I have an if-statement which includes a macro which runs over several lines. I broke the problem down to the fact that CINT seems to get confused when you use macros which run over several lines. I tried the following test program: { #define MACRO (i>2) \ && (i<4) int i = 3; if (MACRO) { cout <<"OK"<<endl; } } According to the C++ standard the "\" is the correct way of splitting long macros over several lines but CINT doesn't seem to like this: Error: reference type $ with no initialization FILE:testcint.C LINE:6 Error: Incorrect referencing of $ FILE:testcint.C LINE:6 *** Interpreter error recovered *** Another even more serious observation: If I run the script with the macro in ONE line: { $define MACRO (i>2) && (i<4) ... } it works of course: root [61] .x testcint.C OK BUT if I then change the value of "i" in the code, let's say to "6" without leaving the root session and run the macro again, I get the following: root [62] .x testcint.C OK root [63] .x testcint.C Warning: Re-initialization enforced macro MACRO FILE:testcint.C LINE:4 *** Interpreter error recovered *** root [64] .x testcint.C root [65] So, at the first try CINT doesn't even notice that I changed the variable, then it produces the error and finally it produces the expected result. Being scared about the fact that it doesn't notice variable changes I tried the following script: { #define MACRO (i>2) && (i<4) for (int i=1;i<6;i++) { if (MACRO) { cout <<i<<"OK"<<endl; } } } I restarted RooT and got the following surprising result: root [0] .x testcint.C 1OK 2OK 3OK 4OK 5OK root [1] .x testcint.C Warning: Re-initialization enforced macro MACRO FILE:testcint.C LINE:4 *** Interpreter error recovered *** root [2] .x testcint.C root [3] .x testcint.C root [4] which means that the change of "i" is not noticed by CINT and the following runs produce (after the previous seen error) no output at all. Now I am not sure if there is a general rule not to use any #define's at all when running in interpreted mode or if that is a bug in CINT when using macros in an if-statement. I didn't try yet to run the macro in the compiled mode, but I assume (or hope) that it will work in that case... Maybe you can clarify the situation and tell me if I am doing something wrong or what the problem might be. Thank you, Frank On Fri, 14 Nov 2003, Rene Brun wrote: > Hi Frank, > > Could you send a small tar file with teh strict minimum to reproduce the > problem? > -a small root file > -your selector.h and.C files > > Rene Brun > > On Fri, 14 Nov 2003, Frank Winklmeier wrote: > > > Hi, > > > > I am getting always a segmentation violation when I run a MakeSelector > > based script the FIRST time in a RooT session: > > > > root [4] chain.Process("xparticle.C") > > Initializing the tree and starting the job ... > > > > > > *** Break *** segmentation violation > > Generating stack trace... > > 0x4056cc8a in G__getitem + 0x5c1 from /home/frank/root/lib/libCint.so > > 0x40569734 in G__getexpr + 0x5ad3 from /home/frank/root/lib/libCint.so > > 0x405b6fa0 in G__exec_statement + 0x1bfc from > > /home/frank/root/lib/libCint.so > > 0x405f4f70 in G__getvariable + 0x52e1 from > > /home/frank/root/lib/libCint.so > > 0x405c14c9 in G__exec_asm + 0xe5a from /home/frank/root/lib/libCint.so > > 0x405b4d15 in G__exec_loop + 0x525 from /home/frank/root/lib/libCint.so > > 0x405b50ea in G__exec_for + 0x18f from /home/frank/root/lib/libCint.so > > 0x405b748a in G__exec_statement + 0x20e6 from > > /home/frank/root/lib/libCint.so > > 0x405b4a2e in G__exec_loop + 0x23e from /home/frank/root/lib/libCint.so > > 0x405b50ea in G__exec_for + 0x18f from /home/frank/root/lib/libCint.so > > 0x405b748a in G__exec_statement + 0x20e6 from > > /home/frank/root/lib/libCint.so > > 0x4058e407 in G__interpret_func + 0x1db7 from > > /home/frank/root/lib/libCint.so > > 0x406080ed in G__CallFunc::ExecInterpretedFunc(G__value*) + 0x11b from > > /home/frank/root/lib/libCint.so > > 0x40607edf in G__CallFunc::ExecInt(void*) + 0x75 from > > /home/frank/root/lib/libCint.so > > 0x40bead7d in TSelectorCint::Process(int) + 0x7b from > > /home/frank/root/lib/libTree.so > > 0x41575367 in TTreePlayer::Process(TSelector*, char const*, int, int) + > > 0x259 from /home/frank/root/lib/libTreePlayer.so > > 0x415750c0 in TTreePlayer::Process(char const*, char const*, int, int) + > > 0xa2 from /home/frank/root/lib/libTreePlayer.so > > 0x40bf2d22 in TTree::Process(char const*, char const*, int, int) + 0x4c > > from /home/frank/root/lib/libTree.so > > 0x40bdd196 in TChain::Process(char const*, char const*, int, int) + 0x44 > > from /home/frank/root/lib/libTree.so > > 0x40c1fa99 in <unknown> from /home/frank/root/lib/libTree.so > > 0x4059ce36 in G__call_cppfunc + 0x263 from > > /home/frank/root/lib/libCint.so > > 0x4058cd2c in G__interpret_func + 0x6dc from > > /home/frank/root/lib/libCint.so > > 0x4057541b in G__getfunction + 0x1295 from > > /home/frank/root/lib/libCint.so > > 0x405f603f in G__getstructmem + 0x82d from > > /home/frank/root/lib/libCint.so > > 0x405f014b in G__getvariable + 0x4bc from /home/frank/root/lib/libCint.so > > 0x4056cc8a in G__getitem + 0x5c1 from /home/frank/root/lib/libCint.so > > 0x4056b91a in G__getexpr + 0x7cb9 from /home/frank/root/lib/libCint.so > > 0x405b0fdf in G__exec_function + 0x1d0 from > > /home/frank/root/lib/libCint.so > > 0x405b772c in G__exec_statement + 0x2388 from > > /home/frank/root/lib/libCint.so > > 0x40555047 in G__exec_tempfile_core + 0x2ce from > > /home/frank/root/lib/libCint.so > > 0x40555224 in G__exec_tempfile_fp + 0x22 from > > /home/frank/root/lib/libCint.so > > 0x405bf2c5 in G__process_cmd + 0x4403 from > > /home/frank/root/lib/libCint.so > > 0x4015ba21 in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) > > + 0x9b from /home/frank/root/lib/libCore.so > > 0x400e2403 in TApplication::ProcessLine(char const*, bool, int*) + 0x56b > > from /home/frank/root/lib/libCore.so > > 0x40d02d4e in TRint::HandleTermInput() + 0x11c from > > /home/frank/root/lib/libRint.so > > 0x40d01d3e in TTermInputHandler::Notify() + 0x24 from > > /home/frank/root/lib/libRint.so > > 0x40d034f0 in TTermInputHandler::ReadNotify() + 0x12 from > > /home/frank/root/lib/libRint.so > > 0x401ba6d9 in TUnixSystem::CheckDescriptors() + 0xed from > > /home/frank/root/lib/libCore.so > > 0x401b9eab in TUnixSystem::DispatchOneEvent(bool) + 0x101 from > > /home/frank/root/lib/libCore.so > > 0x4012e9c1 in TSystem::InnerLoop() + 0x1b from > > /home/frank/root/lib/libCore.so > > 0x4012e95a in TSystem::Run() + 0x78 from /home/frank/root/lib/libCore.so > > 0x400e2e43 in TApplication::Run(bool) + 0x2d from > > /home/frank/root/lib/libCore.so > > 0x40d02920 in TRint::Run(bool) + 0x2e4 from > > /home/frank/root/lib/libRint.so > > 0x0804885e in main + 0x6e from /home/frank/root/bin/root.exe > > 0x42015574 in __libc_start_main + 0xe4 from /lib/tls/libc.so.6 > > 0x08048761 in _Unwind_Resume + 0x31 from /home/frank/root/bin/root.exe > > Root > Function Process() busy flag cleared > > > > root [5] chain.Process("xparticle.C") > > reloading /home/frank/analysis/./xparticle.C 0 > > reloading xparticle.h 0 > > Initializing the tree and starting the job ... > > > > Job finished. > > (Int_t)0 > > root [6] > > > > > > When I run the script the second time it runs without any problems. Does > > anyone know where this strange behaviour comes from? > > I am using RooT version 3.10-01 (RH9). > > > > Thanks, Frank > > > > >
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:16 MET