Difference between revisions of "HowTo debugging"

From OpenFOAMWiki
 
Line 1: Line 1:
If your application crashes and you want to find out more but not create a complete debugging build.
+
If your application crashes it will usually output a stack trace, e.g.
 +
 
 +
#0 Foam::error::printStack(Foam::-Ostream&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
 +
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
 +
#2 Uninterpreted: [0xb7f8b420]
 +
#3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
 +
#4 void Foam::divide<foam::fvpatchfield,>(Foam::GeometricField<double,>&, Foam::GeometricField<double,> const&, Foam::GeometricField<double,> const&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenc eModels.so"
 +
#5 Foam::tmp<foam::geometricfield<double,> > Foam::operator/<foam::fvpatchfield,>(Foam::tmp<foam::geometricfield<double,> > const&, Foam::GeometricField<double,> const&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenc eModels.so"
 +
#6 Foam::turbulenceModels::kEpsilon::correct() in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenc eModels.so"
 +
 
 +
 
 +
There is lots of interesting information in there. It shows the type of error (sigFpe which means a division by zero or any other operation causing an invalid floating point number) and who causes it (operator/ of an fvPatchField). Further down the line is the originator, kEpsilon::correct() which obviously does some divisions. A good guess is that one of the patch fields of k or epsilon is 0.
 +
 
 +
The other common error is a segmentation violation (sigSegv) which is caused by an application accessing memory outside the allocated space. This are nearly always caused by a programming error.
 +
 
 +
If you want to find out more but not create a complete debugging build.
  
 
- Find out from the printed stack trace which files contain the functions that crash. Copy these into your local directory.
 
- Find out from the printed stack trace which files contain the functions that crash. Copy these into your local directory.

Revision as of 08:59, 29 October 2008

If your application crashes it will usually output a stack trace, e.g.

  1. 0 Foam::error::printStack(Foam::-Ostream&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
  2. 1 Foam::sigFpe::sigFpeHandler(int) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
  3. 2 Uninterpreted: [0xb7f8b420]
  4. 3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
  5. 4 void Foam::divide<foam::fvpatchfield,>(Foam::GeometricField<double,>&, Foam::GeometricField<double,> const&, Foam::GeometricField<double,> const&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenc eModels.so"
  6. 5 Foam::tmp<foam::geometricfield<double,> > Foam::operator/<foam::fvpatchfield,>(Foam::tmp<foam::geometricfield<double,> > const&, Foam::GeometricField<double,> const&) in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenc eModels.so"
  7. 6 Foam::turbulenceModels::kEpsilon::correct() in "/home/ivan/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenc eModels.so"


There is lots of interesting information in there. It shows the type of error (sigFpe which means a division by zero or any other operation causing an invalid floating point number) and who causes it (operator/ of an fvPatchField). Further down the line is the originator, kEpsilon::correct() which obviously does some divisions. A good guess is that one of the patch fields of k or epsilon is 0.

The other common error is a segmentation violation (sigSegv) which is caused by an application accessing memory outside the allocated space. This are nearly always caused by a programming error.

If you want to find out more but not create a complete debugging build.

- Find out from the printed stack trace which files contain the functions that crash. Copy these into your local directory.

- Add the files to your Make/files

- in Make/options: add

-DFULLDEBUG -g -O0

to EXE_INC and recompile. The 'FULLDEBUG' causes amongst others full range checking on Lists.