Data in loop getting "stuck" in interpreted mode

Hello again,

This one is a bit creepy, to be honest. I’ve got a piece of code, compiled as a ROOT library and run by a ROOT macro (I’m attaching all the files as an archive). In a nutshell, the macro repeats a certain operation in a loop. Everything compiles fine and when I run the macro in compiled mode
I get what I expect to get (output lines are truncated for brevity):

$ root -q -b run.C+
...
START:
	x,y,z =	   0.000000	   0.000000	-580.000000

STOP:
	x,y,z =	   0.102393	   0.049997	-570.000671
	x,y,z =	   0.210822	   0.099997	-560.000732
	x,y,z =	   0.327561	   0.150002	-550.000000
	x,y,z =	   0.455498	   0.200005	-540.000000
	x,y,z =	   0.598182	   0.250010	-530.000000
...

However, when I run exactly the same code in interpreted mode I get:

$ root -q -b run.C
...
START:
	x,y,z =	   0.000000	   0.000000	-580.000000

STOP:
	x,y,z =	   0.102393	   0.049997	-570.000671
	x,y,z =	   0.210822	   0.099997	-560.000732
	x,y,z =	   0.210822	   0.099997	-560.000732
	x,y,z =	   0.210822	   0.099997	-560.000732
	x,y,z =	   0.210822	   0.099997	-560.000732
...

If I print the value of z before calling T49Trkstep::TrackTo() it is correct, indeed even without printing the loop finishes after the right number of iterations - but TrackTo() appears to be doing nothing. The creepy part is that I display the value of either z or fXstop[2] inside TrackTo(), before calling trkstep_nods(), the code works fine!

I have tried this with 32-bit Linux ROOT version: 5.14.00g, 5.16.00 and 5.18.00a, with identical results.
stuckInInterpreted.tar.gz (11.4 KB)

Could you post a file that we can run directly.
In order to compile I have to add #define NODS in 2 files but then when I run I get many messages like

Magnetic field not initialised, aborting Magnetic field not initialised, aborting x,y,z = 9.471677 5.045805 380.000000 Px,Py,Pz = 0.097254 0.055151 10.000000 Magnetic field not initialised, aborting Magnetic field not initialised, aborting Magnetic field not initialised, aborting Magnetic field not initialised, aborting Magnetic field not initialised, aborting Magnetic field not initialised, aborting Magnetic field not initialised, aborting Magnetic field not initialised, aborting

Rene

Of course! As the field map files are way too big to be posted here and on the other hand most if not all people here have got access to lxPlus, I’ve put the relevant files on CASTOR. You can find the source tarball here:

castor:///castor/cern.ch/user/m/mks/roottalk-testcase.tar.bz2

in principle all you have to do is unpack it, enter the resulting directory, source setup.sh (which, among other things, allows the code to find out where on CASTOR the map files are located) and run root61 -q -b run.C. Please let me know should this approach not work.

I’ve run into another problem which seems to be related to the same source, even though it’s in a completely different program - not just different code mind you, this time it’s a full-blown, compiled+linked ROOT library loaded into a macro by gSystem->Load().

The code fragment in question looks like this:

[code] Float_t posx = 0., posy = 0., posz;
for (Int_t a = 1; a <= nPlanes; ++a) {
posz = -492.17 - (224.8 / (nPlanes - 1)) * (a - 1);
const Int_t trkRes = TS->TrackTo(posz);
if ((trkRes == 0) || (trkRes == 2)) {
posx = TS->GetX();
posy = TS->GetY();

     if ((TMath::Abs(posx) < 85.) && (TMath::Abs(posy) < 40.) && (TMath::Abs(posx) > 12.))
        track2->SetPlaneValues(0, a, posx, posy, posz);
  }

}
[/code]

where nPlanes is passed from the outside and TS in an instance of T49Trkstep as used in the first problem case.
In the code above, SetPlaneValues never gets called because regardless of what GetX() actually returns posx in the if statement always equals 0, thus making the condition false. However, if I add either
cout << posx;
or
cout << TS->GetX();
before the if statement, not only do correct values get displayed on the screen but also the code starts to work as it should. To make it even more interesting, I needn’t use cout or cerr to “fix” the problem - when I created an output file stream pointing to /dev/null and used it instead, it “unblocked” posx too.

Again for this type of problem, we cannot do anything without having the shortest possible running piece of code reproducing the problem.

Rene