Hi, A simulation program I'm running on a Linux RedHat 9.0 computer using Geant4.6.2.p02 works perfectly when linking it with Geant4 version 6.2.p01, but ends with a segmentation fault when linked with Geant4 version 6.2.p02. The problem seems to be related to the use of a readout geometry (if I do not use it, it works all right). To find out where the problem is I wrote a short test code which reproduces the problem. You can get it from ftp://guest:time@ftp.metas.ch/voros/totabs.tgz . If you extract the files from this archive, you will get a directory called totabs of the same kind as for the Geant4 examples: just cd into it, gmake (the executable will be called "totabs") and run the code. The vis.mac file will be executed automatically by the code and then just give the command /run/beamOn 1 : you will get the segmentation fault immediately. I compiled the full Geant4 libraries in debug mode and ran this code using valgrind. Here is an outline of the output: > valgrind --gen-suppressions=yes --num-callers=20 --skin=memcheck ../../bin/Linux-g++/totabs ==13308== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==13308== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==13308== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==13308== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==13308== Estimated CPU clock rate is 2392 MHz ==13308== For more details, rerun with: -v ==13308== ************************************************************* Geant4 version $Name: geant4-06-02-patch-02 $ (26-October-2004) Copyright : Geant4 Collaboration Reference : NIM A 506 (2003), 250-303 WWW : http://cern.ch/geant4 ************************************************************* .......... Idle> /run/beamOn 1 .......... totabsEventAction::BeginOfEventAction : ---> Begin of event: 0 --------- Ranecu engine status --------- Initial seed (index) = 0 Current couple of seeds = 9876, 54321 ---------------------------------------- ********************************************************************************************************* * G4Track Information: Particle = e-, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 0 fm 0 fm -3.2 cm 5.33 MeV 0 eV 0 fm 0 fm World initStep 1 0 fm 0 fm 0 fm 5.33 MeV 5.11 keV 3.2 cm 3.2 cm World Transportation 2 0 fm 0 fm 0 fm 5.33 MeV 0 eV 0 fm 3.2 cm AbsorberRPhiZDiv Transportation 3 0 fm 0 fm 0 fm 5.33 MeV 0 eV 0 fm 3.2 cm World Transportation 4 0 fm 0 fm 0 fm 5.33 MeV 0 eV 0 fm 3.2 cm Absorber Transportation ==13308== ==13308== Invalid read of size 4 ==13308== at 0x41E1E8F2: std::_Rb_tree<G4Material*, std::pair<G4Material* const, G4MaterialCutsCouple*>, std::_Select1st<std::pair<G4Material* const, G4MaterialCutsCouple*> >, std::less<G4Material*>, std::allocator<std::pair<G4Material* const, G4MaterialCutsCouple*> > >::find(G4Material* const&) (stl_tree.h:1267) ==13308== by 0x41E1DE64: std::map<G4Material*, G4MaterialCutsCouple*, std::less<G4Material*>, std::allocator<std::pair<G4Material* const, G4MaterialCutsCouple*> > >::find(G4Material* const&) (stl_map.h:332) ==13308== by 0x41E1CEB5: G4Region::FindCouple(G4Material*) (G4Region.icc:202) ==13308== by 0x41E1BA71: G4LogicalVolume::UpdateMaterial(G4Material*) (G4LogicalVolume.icc:255) ==13308== by 0x41E1C775: G4ParameterisedNavigation::LevelLocate(G4NavigationHistory&, G4VPhysicalVolume const*, int, Hep3Vector const&, Hep3Vector const*, bool, Hep3Vector&) (G4ParameterisedNavigation.icc:155) ==13308== by 0x41E18065: G4Navigator::LocateGlobalPointAndSetup(Hep3Vector const&, Hep3Vector const*, bool, bool) (G4Navigator.cc:375) ==13308== by 0x41614986: G4Navigator::LocateGlobalPointAndUpdateTouchable(Hep3Vector const&, Hep3Vector const&, G4VTouchable*, bool) (G4Navigator.icc:312) ==13308== by 0x41C5D5C6: G4VReadOutGeometry::FindROTouchable(G4Step*) (G4VReadOutGeometry.cc:124) ==13308== by 0x41C5D4C6: G4VReadOutGeometry::CheckROVolume(G4Step*, G4TouchableHistory*&) (G4VReadOutGeometry.cc:105) ==13308== by 0x4031A4E1: G4VSensitiveDetector::Hit(G4Step*) (G4VSensitiveDetector.hh:119) ==13308== by 0x41C1ED6C: G4SteppingManager::Stepping() (G4SteppingManager.cc:222) ==13308== by 0x41C280F5: G4TrackingManager::ProcessOneTrack(G4Track*) (G4TrackingManager.cc:118) ==13308== by 0x41B88FA2: G4EventManager::DoProcessing(G4Event*) (G4EventManager.cc:174) ==13308== by 0x41B896F0: G4EventManager::ProcessOneEvent(G4Event*) (G4EventManager.cc:324) ==13308== by 0x41B12F1F: G4RunManager::DoEventLoop(int, char const*, int) (G4RunManager.cc:218) ==13308== by 0x41B12935: G4RunManager::BeamOn(int, char const*, int) (G4RunManager.cc:127) ==13308== by 0x41B19DD1: G4RunMessenger::SetNewValue(G4UIcommand*, G4String) (G4RunMessenger.cc:248) ==13308== by 0x4215F13D: G4UIcommand::DoIt(G4String) (G4UIcommand.cc:206) ==13308== by 0x42171454: G4UImanager::ApplyCommand(char const*) (G4UImanager.cc:397) ==13308== by 0x42170E47: G4UImanager::ApplyCommand(G4String) (G4UImanager.cc:341) ==13308== Address 0x24 is not stack'd, malloc'd or free'd ==13308== ==13308== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- Segmentation fault (core dumped) > I hope this helps. Best regards, SĂĄndor
Thanks for the detailed report. I will investigate it.
The bug was identified and fixed. The fix is to be included in Geant4 7.0 release.