Problem 969 - Segmentation fault in G4Torus::SolveNumericJT
Summary: Segmentation fault in G4Torus::SolveNumericJT
Status: RESOLVED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: geometry/solids (show other problems)
Version: 8.2
Hardware: All Linux
: P3 normal
Assignee: tatiana.nikitina
URL:
Depends on:
Blocks:
 
Reported: 2007-09-20 12:21 CEST by Chris Rogers
Modified: 2008-02-08 09:52 CET (History)
1 user (show)

See Also:


Attachments
Verbose tracking and valgrind output where the bug was observed (359.08 KB, text/x-log)
2007-09-20 12:21 CEST, Chris Rogers
Details

Note You need to log in before you can comment on or make changes to this problem.
Description Chris Rogers 2007-09-20 12:21:58 CEST
Created attachment 7 [details]
Verbose tracking and valgrind output where the bug was observed

I am an app developer on G4MICE, simulation of muon ionisation cooling for a neutrino factory or muon collider.

I get a segmentation fault in the method:

G4Torus::SolveNumericJT(CLHEP::Hep3Vector const&, CLHEP::Hep3Vector const&, double, bool)

Valgrind reports "Invalid read of size 8" which means that Geant4 is trying to read an uninitialised bit of memory (e.g. reading past the end of an array).

Geant4 tracks happily through the torus for about 70 particles, so I think everything is initialised okay and the problem is with geant4. But when it makes the first step on ~ the 70-80th particle I hit the segmentation fault.

I am using G4 v4.8.2p01, running on a 64 bit linux (SuSe) machine. The Torus is initialised with pRMin 1.0  mm, pRMax 50.0 mm, pRTor 110.0 mm, pSPhi 0.0   degree, pDPhi 360.0  degree.

I attach the valgrind output. This is with Geant4 running in a highly verbose mode, so you can see all of the tracking details. I truncated the file so you only see the last two events (to save you having a massive file to read).

Hoping you can resolve the issue! Let me know if you need more details, or if I'm doing something obviously wrong.

Regards,
Chris
Comment 1 tatiana.nikitina 2008-02-08 09:52:36 CET
Fix for this problem is proposed in 4.9.1.