Geant4 and C++ code analisys

Hello all!

I have stupid question… does GEANT4 developers use routinely a static C++ Code analysis during its code preparation for deploy?

I have this question because I use GEANT4 under Windows and VisualStudio has the compiler option “Use Code Analisys”. When I switch it ON I see a lots of messages about uninitialized pointers, mixed 4 and 8 byte integer operations etc… and especially it is important in the memory management code.

I am sure, it would reduce a number of possible G4 crashes which waste the user time. .

Vyacheslav

Hi, for your information, the Geant4 code is regularly analysed through the Coverity Static Analyser tool suite and the Valgrind tool on Linux systems. It should free from any serious memory management issue.
We are not using VisualStudio for static analysis on Windows.

1 Like

We are also gradually deploying use of clang-tidy for higher level development-time analysis in addition to the regular Coverity/Valgrind CI runs. You don’t say which version of Geant4 version you’re using, which may also make a difference.

1 Like

Hi, I use the latest version of GEANT4…

Anyway, I can see the messages like this:

[D:/geant4-v11.1.1/source/geometry/solids/specific/include/G4Voxelizer.icc:94] (error) Dereference of an invalid iterator: fBoundaries[i].end() [derefInvalidIterator]

in the following code:
inline
G4bool G4Voxelizer::GetPointVoxel(const G4ThreeVector& p,
std::vector& voxels) const
{
for (auto i = 0; i <= 2; ++i)
{
if (p[i] < *fBoundaries[i].begin() || p[i] > *fBoundaries[i].end())
{
return false;
}
}

[D:/geant4-v11.1.1/source/geometry/solids/specific/src/G4Tet.cc:634] (error) Array ‘iface[4][3]’ accessed at index iface[4][0], which is out of bounds. [arrayIndexOutOfBounds]

in code
G4ThreeVector G4Tet::GetPointOnSurface() const
{
constexpr G4int iface[4][3] = { {0,1,2}, {0,2,3}, {0,3,1}, {1,2,3} };

// Select face
G4double select = fSurfaceArea*G4QuickRand();
G4int i = 0;
for ( ; i < 4; ++i) { if ((select -= fArea[i]) <= 0.) break; }

// Set selected triangle
G4ThreeVector p0 = fVertex[iface[i][0]];
G4ThreeVector e1 = fVertex[iface[i][1]] - p0;
G4ThreeVector e2 = fVertex[iface[i][2]] - p0;

etc… like unrealized mutex…

Vyacheslav

just about mutex…

D:\geant4-v11.1.1\source\geometry\biasing\src\G4IStore.cc(172): warning C26115: Failing to release lock “G4IStore::IStoreMutex” in function “G4IStore::GetImportance”.

G4double G4IStore::GetImportance(const G4VPhysicalVolume& aVolume,
G4int aRepNum) const
{
#ifdef G4MULTITHREADED
G4MUTEXLOCK(&G4IStore::IStoreMutex);
#endif
SetInternalIterator(G4GeometryCell(aVolume, aRepNum));
auto gCellIterator = fCurrentIterator;
if (gCellIterator == fGeometryCelli.cend())
{
Error(“GetImportance() - Region does not exist!”);
return 0.;
}
G4double importance_value = (*fCurrentIterator).second;
#ifdef G4MULTITHREADED
G4MUTEXUNLOCK(&G4IStore::IStoreMutex);
#endif
return importance_value;
}

Related to this, and just out of interest, was anyone on the Geant4 team involved with this blog post, or were the results made available to the team?

See here: 1534 – PVS-Studio
… and here: 1876 – PVS-Studio, Geant 4 version 10.02

1 Like

Vyacheslav,

various static analyzers are useful, the Coverity is a good one, but you should know that >99% of static analyzer warnings are simply requirement of pedantic C++ code implementation, they are not real problems. Majority of real problems, which may be detected by a static analyser are fixed.

VI