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