Message: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install) Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Question composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install) 

Forum: Installation and Configuration
Date: 26 Jun, 2012
From: Dylan <Dylan>

Dear Sirs/Madams,

I am working with the example code composite_calorimeter and am currently experiencing a segmentation fault during run time. The fault occurs with completely unmodified example code, as packaged on install, as well as my modified code, and occurs fastest when running 300 GeV Pions (pi-) into the calorimeter, via:

/gun/particle pi-
/gun/energy 300 GeV
/run/beamOn 100

I have tested this with two different versions of Geant 4 on two separate operating systems, with completely unmodified composite_calorimeter code. The details are as follows:

I have tested using Geant 4.9.3 on Mac OSX 10.6.8, and Geant 4.9.3.p02. The CLHEP installed is the recommended version 2.0.4.5 and I have Open Scientist Batch version 16.11 installed with the AIDA interface included. The environment is set up as follows, in a bash shell:


export DYLD_LIBRARY_PATH=/Applications/CLHEP/lib
. /Applications/geant4.9.3.p02/env.sh
export ROOTSYS=/Applications/root
export DYLD_LIBRARY_PATH=$ROOTSYS/lib:$DYLD_LIBRARY_PATH
. /Applications/osc_batch/16.11/aida-setup.sh
. /Applications/root/bin/thisroot.sh

. envExample.sh
make clean
make


I have run several of my own debugs since discovering the fault and the crash always occurs when the active process from PostStepPoint is a Decay, SubType 201, and the creator process for the current track is LambdaInelastic, SubType 121. The following is debug output from CCalSteppingAction at the point of the crash:


Process Name from PostStepPoint is Decay
Process Type from PostStepPoint is 6
Process Type Name from PostStepPoint is Decay
Process Subtype from PostStepPoint is 201


Track creator process from 'aStep' is: LambdaInelastic
Process Type from Track creator process is 4
Process Type Name from Track creator process is Hadronic
Process Subtype from Track creator process is 121


These conditions occur a handful of times during the run, before the crash, so there must be another factor at play, causing the bug to occur.
The fault is caused by a problem involving the TSliceID variable in CCalSteppingAction::UserSteppingAction (located in CCalSteppingAction.cc).

A global time value is returned via PostStepPoint->GetGlobalTime() and this value rounded to an integer which is then used to reference the 200 member timeDeposit[] array and increment the appropriate energy to the corresponding member of the array.

However, I have found that a segmentation fault is occurring and causing the program to crash, due to this global time value returned spontaneously taking an extremely large value (after a random number of steps, usually several thousand, which varies with initial conditions). For example 2.0177806e+12 ns, or 2.525698e+11 ns, when it should be taking a value between 0 and 200 nanoseconds.

This somehow causes the rounding operation which occurs in the following line to assign a large negative integer to TSliceID. This value is always the same, regardless of the global time returned from PostStepPoint, setting TSliceID = -2147483648:

TSliceID = static_cast<int>( (PostStepPoint->GetGlobalTime() ) / nanosecond);

The segmentation fault occurs when CCalSteppingAction::UserSteppingAction tries to write to the -2147483648th member of the 200 member timeDeposit[] array, here:

timeDeposit[TSliceID] += aStep->GetTotalEnergyDeposit() / GeV;

I am posting here to see if anyone knows why this extremely large value is being returned by PostStepPoint->GetGlobalTime (rather than a value in the range 0 to 200 nanoseconds), or if anyone can suggest a possible cause or solution to this crash.

To confirm this problem was present with a fresh install, I completely removed Geant 4 from OSX and reinstalled it, as per the instructions in the installation guide, to version 4.9.3.p02. The bug occurred again, unchanged, with completely unmodified example code.

The problem is also occurring independently on a Linux system (Fermi Linux lts30 INSTALL for FermiGenericDesktopOffsite), with an install of Geant version 4.9.4.p02. The bug and debug data occur exactly the same with this install. The CLHEP version installed here is 2.1.0.1, and version 16.11.5 of OpenScientist batch is installed.

If it is a problem with my install, environment, supporting software, or a build error, I would ask if anyone has any suggestions for a possible solution.

Best regards,

Dylan

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Note: Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install)   (Dylan - 29 Jun, 2012)
(_ Warning: Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install)   (Ben Morgan - 02 Jul, 2012)
1 None: Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install)   (Dylan - 03 Jul, 2012)
2 Feedback: Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install)   (Dylan - 09 Jul, 2012)
 Add Message Add Message
to: "composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install)"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]