When code is compiled, the compiled (e.g. gcc) can take an option whether to perform additional optimization procedures to make code run faster. It essentially alters the source code that is compiled. A simple example would be:

int a = 3;

...

if (a < 2) {

  blah

} else {

  blech

}

The compiler can see that if "a" is never altered from the value 3, then the value test in the "if" statement is unnecessary and the code can simply be reduced to:

blech

The code runs faster because the "if" statement is never executed.

There are many such things that can be done, but by doing such optimizations, the original source code does not necessarily match the code that is actually compiled in the end. This means that running in a debugger may not be able to actually clearly show the source code where things are happening (compiled code != code in the files).

In STAR, we provide both an optimized compilation, and an unoptimized compilation, where the latter is best used when debugging code, and the former is best used when code is running well. If you look under $STAR/.sl73_gcc485/ you will see capitalized OBJ, LIB, and BIN subdirectories where the optimized compilations are, and uncapitalized where the unoptimized compilations are. You access the optimized by doing this:

unsetenv NODEBUG

stardev

or

unsetenv NODEBUG

starver SL22a

And for unoptimized, you can do:

setenv NODEBUG yes

stardev

Hopefully you get the idea. So if you don't have these in your .cshrc, then you want to do it before compiling or running root4star:

unsetenv NODEBUG

stardev

cons

In your xml files for your jobs, you would then need to have

Note: if you compile optimized, but run root4star unoptimized, you won't pick up your local compile. Same for compiling unoptimized by running optimized. The NODEBUG environment variable tells either cons or root4star to use the capital LIB and BIN subdirectories, so if those don't exist locally, then the versions under $STAR will be taken.

Hope that helps,