Difference between revisions of "HowTo debugging"
Line 11: | Line 11: | ||
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. | 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. | ||
+ | |||
+ | From experience sigfpe originate from three sources: | ||
+ | * as above - division by 0 from having an initial field set to 0. | ||
+ | * when using floatTransfer = 1. This will truncate doubles into floats before doing parallel transfer so if the double does not fit it will produce a sigfpe. Check the traceback for a call to 'compressedSend'. | ||
+ | * when using FOAM_SETNAN (initialises allocated memory to NaN) and accessing uninitialised memory. | ||
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. | 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. | ||
Line 16: | Line 21: | ||
If you want to find out more but not create a complete debugging build. | 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 | -DFULLDEBUG -g -O0 | ||
to EXE_INC and recompile. The 'FULLDEBUG' causes amongst others full range checking on Lists. | to EXE_INC and recompile. The 'FULLDEBUG' causes amongst others full range checking on Lists. |
Revision as of 08:47, 17 April 2009
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.
From experience sigfpe originate from three sources:
- as above - division by 0 from having an initial field set to 0.
- when using floatTransfer = 1. This will truncate doubles into floats before doing parallel transfer so if the double does not fit it will produce a sigfpe. Check the traceback for a call to 'compressedSend'.
- when using FOAM_SETNAN (initialises allocated memory to NaN) and accessing uninitialised memory.
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.