Hello, The simulation program I'm running on a Linux RedHat 9.0 computer using Geant4.6.2.p01 and the LHEP_PRECO_HP hadronic physics finishes with a segmentation fault. I then compiled my code and the Geant4 libraries in debug mode and ran it with the Valgrind memory management debugger to try find out where the problem is. It turned out that some invalid stuff was done in some classes of the LHEP_PRECO_HP package. Then I tried to make my (rather large) code shorter to reproduce the problem in a simple test case. I ended up with a very short code using only LHEP_PRECO_HP as the physics list initialised in the main() method (no other specific PhysicsList classes are needed) and a trivial geometry (a quartz cylinder in a World filled with air, onto which a 500 MeV proton impinges). Valgrind still sees some problems in some classes of the LHEP_PRECO_HP package, but yet no segmentation fault occurs any more (so it looks like the precise outcome depends on what is defined in the geometry and analysis classes). Nevertheless, the Valgrind output allows to see precisely where some uninitialised value(s) are used in the LHEP_PRECO_HP package. Since it is simpler to use this shorter test program than my original large code, I put it on ftp://guest:time@ftp.metas.ch/voros/LHEP_PRECO_HP.tar.gz. If you extract the files from this archive, you will get a directory called LHEP_PRECO_HP of the same kind as for the Geant4 examples: just cd into it, gmake (the executable will be called "totabs") and run the code (with Valgrind if you have it in order to see the problem, otherwise you won't notice any problem). If you prefer, I also put into this LHEP_PRECO_HP directory a file called valgrind.out which contains the output of a full Geant4 Valgrind session I ran on my computer, giving only 2 commands: "/run/beamOn 10" and "exit" after the vis.mac file was executed automatically by the program. Valgrind reports some uninitialised value(s) problems in event number 8, as well as some reading at a previously free'd address in the exit procedure. This Valgrind output reports the following problems in event number 8: 1) Conditional jump or move depends on uninitialised value(s) in G4NeutronHPPhotonDist.cc on line 205 if(repFlag==1) 2) Conditional jump or move depends on uninitialised value(s) in G4NeutronHPPhotonDist.cc on line 339 else if(repFlag == 2) 3) Use of uninitialised value of size 8 in G4NeutronHPPhotonDist.hh on line 109 inline G4double GetLevelEnergy() {return theBaseEnergy;} 4) Conditional jump or move depends on uninitialised value(s) in G4NeutronHPInelasticCompFS.cc on line 314 if(theFinalStatePhotons[it]->NeedsCascade()) and the NeedsCascade() method is defined in G4NeutronHPPhotonDist.hh on line 107 as "inline G4bool NeedsCascade() {return repFlag==2;}" All the unitialised values "repFlag" (in 1,2,4) and "theBaseEnergy" (in 3) should have been read in from an "aDataFile" object in method G4NeutronHPPhotonDist::InitMean(std::ifstream & aDataFile), so it looks like this method was not called at all since a test on the value of "repFlag" is performed there, which should have thrown an exception (unless the uninitialised value of "repFlag" should by chance have been equal to 1 or 2, which is certainly unlikely). The G4NeutronHPPhotonDist::InitMean(std::ifstream & aDataFile) should probably have been called in G4NeutronHPInelasticCompFS.cc on line 119: theFinalStatePhotons[it]->InitMean(theData); on the condition "dataType==12", the "dataType" value being read in the same file as mentioned above. Since I don't know exactly which file this is and how to read it, I unfortunately couldn't follow this program flow any futher. I hope that an expert knowing the way this file reading works can easily find out where the problem lies. Finally concerning the problems in the "exit" procedure, I did not examine in details the Valgrind messages since I thought they might be linked to the previous errors, and thus it would be better to first solve these ones. Nevertheless, you can have a look at the "exit" procedure's errors in the valgrind.out file provided in the tar archive mentioned above. Best regards, Sandor
Hi, I tested the code above (in the LHEP_PRECO_HP.tar.gz archive) again while linking it with the latest Geant4 patch release 6.2.p02 . The problem is still there, so this new release does not solve it. The only (little) difference is that valgrind sees it in events 1,8 and 9 instead of number 8 only. In case you are intesrested I put the output of the valgrind session obtained by using latest release 6.2.p02 in file ftp://guest:time@ftp.metas.ch/voros/LHEP_PRECO_HP_valgrind_g4.6.2.p02.out.gz . Don't hesitate to contact me if more information is needed. Best regards, Sandor
Hi, I verified this carefully, and it seems all is fine. Valgrind unfortunatly has problems with the neutron transport code. Your's is not the first report of problems with undefined values. Up to now, inserting printout at the neuralgic point has always shows that valgrind was wrong. In more general, when you find the valgrind complains in connection with a variable that was initialized from a file, you can safely ignore it. The logic goes like this: Each object in initialized in one go. If there is one variable that was not initialized, as a consequence, none of them can be initialized. Many greetings, Hans-Peter.