Script segfault when called from shell script

I’m having trouble debugging an issue where a set of scripts, when called from the command line, ie:

root -b -q -l script1.C script2.C

Complete without error or problem

but when called from a shell script (with similar syntax) segfaults at the same place every time.

Any help or advice would be appreciated.


obvious candidates would be environment variables or pwd. But to really know what’s happening we will (obviously) need the scripts and / or at least the error message + traceback.

Cheers, Axel.

The script:


cat parH1H2wa.C > ${dir}/r$1/1014insp.log
#cat "Starting job $@" >> r$@/1014insp.log
#ruby insp.rb $@ >> r$@/1014insp.log 2>&1
echo $1 | root -q -l -b ${dir}/parH1H2wa.C ${dir}/wanet2.C #>> ${dir}/r$1/1014insp.log 2&>1

The error:

[11:06:31]pankow@ldas-pcdev1:1014>./ 22
ROOT initialization starting.
Loading Wavelet Analysis Tool library.
Loading WAT macros.
Done. Starting.
Processing /archive/home/pankow/m31event/inspiral/output/background/1014/parH1H2wa.C...
Runnum/runID: 22 22
Processing /archive/home/pankow/m31event/inspiral/output/background/1014/wanet2.C...

 network of H1xH2 detectors

maximum time delay between detectors: 0
       maximum time delay difference: 0
           skymap angular resolution: 1
          skymap size in polar angle: 46, 48
      skymap size in azimuthal angle: 7.5, 9.5
                          constraint: 0.02 2

Tue Nov 13 11:06:39 PST 2007
job ID: 22
Input : /archive/home/pankow/m31event/inspiral/input/,  label: CWB
Output: /archive/home/pankow/m31event/inspiral/output/background/1014/r22/,  label: CWB
Reading injection log: /archive/home/pankow/m31event/inspiral/output/background/1014/r22//injectionList.txt
type  0 has been assined to waveform insp_1.400000-10.000000
GPS: 854378484.000000 saved,  injections: 1

 *** Break *** segmentation violation
 Generating stack trace...
 0x00002ba8545fea56 in detector::readFilter(char const*) + 0x346 from /archive/home/pankow/wat/wat-4.7.0/lib/
 0x00002ba85465dad5 in <unknown> from /archive/home/pankow/wat/wat-4.7.0/lib/
 0x00002ba851b81c0b in G__call_cppfunc + 0x21b from /opt/lscsoft/root/lib64/
 0x00002ba851b6c06e in G__interpret_func + 0x143e from /opt/lscsoft/root/lib64/
 0x00002ba851b60428 in G__getfunction + 0x2288 from /opt/lscsoft/root/lib64/
 0x00002ba851bf933b in G__getstructmem + 0x5eb from /opt/lscsoft/root/lib64/
 0x00002ba851bf1313 in G__getvariable + 0x953 from /opt/lscsoft/root/lib64/
 0x00002ba851b33327 in G__getitem + 0x97 from /opt/lscsoft/root/lib64/
 0x00002ba851b34e27 in G__getexpr + 0x737 from /opt/lscsoft/root/lib64/
 0x00002ba851ba0f12 in G__exec_statement + 0xda2 from /opt/lscsoft/root/lib64/
 0x00002ba851ba414a in G__exec_loop + 0x29a from /opt/lscsoft/root/lib64/
 0x00002ba851ba4a6c in G__exec_for + 0x1dc from /opt/lscsoft/root/lib64/
 0x00002ba851ba1e8b in G__exec_statement + 0x1d1b from /opt/lscsoft/root/lib64/
 0x00002ba851b20075 in G__exec_tempfile_core + 0x2c5 from /opt/lscsoft/root/lib64/
 0x00002ba851b20392 in G__exec_tempfile + 0x12 from /opt/lscsoft/root/lib64/
 0x00002ba851bb08b7 in G__process_cmd + 0x6227 from /opt/lscsoft/root/lib64/
 0x00002ba8511eec9a in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) + 0x1da from /opt/lscsoft/root/lib64/
 0x00002ba851129935 in TApplication::ProcessFile(char const*, int*) + 0x425 from /opt/lscsoft/root/lib64/
 0x00002ba851126dcf in TApplication::ProcessLine(char const*, bool, int*) + 0x53f from /opt/lscsoft/root/lib64/
 0x00002ba8533dabc4 in TRint::Run(bool) + 0x164 from /opt/lscsoft/root/lib64/
 0x000000000040108d in main + 0x4d from /opt/lscsoft/root/bin/root.exe
 0x00002ba853bd840f in __libc_start_main + 0xef from /lib64/
 0x0000000000400fa9 in TApplicationImp::ShowMembers(TMemberInspector&, char*) + 0x41 from /opt/lscsoft/root/bin/root.exe


hmm, and echo 22| root -q -l -b /archive/home/pankow/m31event/inspiral/output/background/1014/parH1H2wa.C /archive/home/pankow/m31event/inspiral/output/background/1014/wanet2.C works? Really absolutely sure, also with the echo and -q -l -b and the exact same scripts? What about bash echo 22| root -q -l -b /archive/home/pankow/m31event/inspiral/output/background/1014/parH1H2wa.C /archive/home/pankow/m31event/inspiral/output/background/1014/wanet2.C
Does that do it? Maybe you could compare env from the prompt and env from inside the script?

Cheers, Axel.

Well… it does do something. If I start a new shell, ie do what you suggested:

echo 22| root -q -l -b /archive/home/pankow/m31event/inspiral/output/background/1014/parH1H2wa.C /archive/home/pankow/m31event/inspiral/output/background/1014/wanet2.C

it crashes in the same way it would from the script.[/code]

OK, very good :slight_smile: Now compare the output of env on your prompt and in the sub-shell. When starting bash something must be changed by .bash_profile or /etc/profile or one of those.
Cheers, Axel.

Okay… looks like I need to move to the cluster admins for help then. Thanks!

So, it’s been fixed. (Sort of – it now breaks further down the line, with less explanation)

However, I’m more concerned with how it was fixed.

The reading of command line arguments was originally accomplished by an echo into the stdin of the root process. This was in a script wide scope. It was then changed to being passed as a parameter to a function inside the script.

Why does this work? Isn’t this a bit curious?

Thanks for any advice.


it’s hard to tell without being able to reproduce it. I believe it might be due to a conflict in who redirects what; maybe bash and root get in each other’s way when accessing stdin. Passing it as a function parameter func.C(22) is portable and known to work. So your work-around is the proper one.

Cheers, Axel.