RE: [ROOT] Segmenation violation on first run of script

From: Philippe Canal (pcanal@fnal.gov)
Date: Thu Nov 20 2003 - 00:58:35 MET


Hi Frank,

In your case a macro is not really the best coding practice (even if it
worked).

If you really needed complex macro, you can either use the external
preprocessor
or better compile your script using ACLiC.

You can also simple use a named script.

For example just do:

bool iftest(int i) { return (i>2) && (i<4); }

void testcint() {
int i = 3;

if (iftest(i)) {
   cout <<"OK"<<endl;
}
}

and use it as before

root [62] .x testcint.C
OK

The only different is that 'i' is not declared at the global scope.

Cheers,
Philippe.

-----Original Message-----
From: Frank Winklmeier [mailto:frank.winklmeier@colostate.edu]
Sent: Friday, November 14, 2003 6:53 PM
To: Rene Brun
Cc: roottalk@pcroot.cern.ch; Philippe Canal
Subject: Re: [ROOT] Segmenation violation on first run of script


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