[santiagomarquezd]

Hi friends, I'm trying to go within fvcDdtPhiCorr with gdb, libfiniteVolume.do seems to be compiled with debug switches but I can't do it. This is the output:

(gdb) where
#0 0x00007ffff679175e in Foam::fv::EulerDdtScheme<Foam::Vector<double> >::fvcDdtPhiCorr(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) () from /home/santiago/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPDebug/libfiniteVolume.so
#1 0x00000000004aba04 in Foam::fvc::ddtPhiCorr<Foam::Vector<double> > (rA=..., rho=..., U=..., phi=...) at /home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/finiteVolume/lnInclude/fvcDdt.C:147
#2 0x0000000000450da3 in main (argc=1, argv=0x7fffffffd278) at pEqn.H:12
(gdb) l
142 {
143 return fv::ddtScheme<Type>::New
144 (
145 U.mesh(),
146 U.mesh().ddtScheme("ddt(" + rho.name() + ',' + U.name() + ')')
147 )().fvcDdtPhiCorr(rA, rho, U, phi);
148 }
149
150
151 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
(gdb) down
Bottom (innermost) frame selected; you cannot go down.

I set the breakpoint in

(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x00007ffff679175e finiteVolume/ddtSchemes/EulerDdtScheme/EulerDdtScheme.C:415
breakpoint already hit 1 time

EulerDdtScheme has the method fvcDdtPhiCorr which is called in fvcDdt.C nevertheless my deepest access is in fvcDdt.C.

Any clues about how to go down?

Thanks in advance.

[gwierink]

Hi Santiago,

I had some similar issue with debugging in the past. In my case it turned out that I needed to change the optimization in wmake rules. That is, change O3 to e.g. O0 (check compiler optimization) in $FOAM_SRC/wmake/rules/linuxGcc/c++Opt:

c++OPT      = -O3

Perhaps also in some other rules, but anyways changing the optimization level helped for me.

[akidess]

Gijsbert, WM_COMPILE_OPTION=Debug already disables optimization I believe.

[santiagomarquezd]

Hi, I'd compiled with:

WM_COMPILE_OPTION=Debug

nevertheless I changed the options Gijsbert said and then did:

santiago@elduque:~/OpenFOAM/OpenFOAM-1.6.x/src$ wmake libso finiteVolume

finally I obtained:

...
...
...

SOURCE=cfdTools/general/fieldSources/pressureGradientExplicitSource/pressureGradientExplicitSource.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O0 -fdefault-inline -ggdb3 -DFULLDEBUG -DNoRepository -ftemplate-depth-40 -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/triSurface/lnInclude -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/meshTools/lnInclude -IlnInclude -I. -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPDebug/pressureGradientExplicitSource.o

SOURCE=cfdTools/general/fieldSources/timeActivatedExplicitSource/timeActivatedExplicitSource.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O0 -fdefault-inline -ggdb3 -DFULLDEBUG -DNoRepository -ftemplate-depth-40 -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/triSurface/lnInclude -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/meshTools/lnInclude -IlnInclude -I. -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPDebug/timeActivatedExplicitSource.o

'/home/santiago/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPDebug/libfiniteVolume.so' is up to date.

so no changes seems have to be done by the recompilation...

Regards.

[gwierink]

Hi Santiago,

There has been a change, actually. When the optimization level is changed (see the red -O0 below), it is easier for the debugger to find the possible problem that was actually coded. If you have a compiler optimization (a high one like O3), you basically give the compiler the option to change optimize certain instructions when writing machine instructions. This is often an advantage, but when you're trying to find out what's wrong it's often better to do a "one-to-one compilation". So, in a way nothing changed, but it should be easier to find the bug ...

SOURCE=cfdTools/general/fieldSources/pressureGradientExplicitSource/pressureGradientExplicitSource.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O0 -fdefault-inline -ggdb3 -DFULLDEBUG -DNoRepository -ftemplate-depth-40 -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/triSurface/lnInclude -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/meshTools/lnInclude -IlnInclude -I. -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude -I/home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPDebug/pressureGradientExplicitSource.o

[santiagomarquezd]

Gijsbert, thx for the answer, I understand that part and this is the behaviour I'd spected, nevertheless it seems not to have effects, let's see:

$ ldd ~/OpenFOAM/santiago-1.6.x/applications/bin/linuxGccDPDebug/interFoamParts

...

libfiniteVolume.so => /home/santiago/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPDebug/libfiniteVolume.so (0xb645e000)

...

my solver seems to be linking against the proper library, respect of this library:

$ ls -lhtr /home/santiago/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPDebug/libfiniteVolume.so

-rwxr-xr-x 1 santiago santiago 252M May 19 13:25 /home/santiago/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPDebug/libfiniteVolume.so

it is what was compiled in my last post with all the debug switches activated (I thing it was the same the first time). Now, the results in gdb:

(gdb) b EulerDdtScheme.C:415

Breakpoint 2, 0xb74c7c9b in Foam::fv::EulerDdtScheme<Foam::Vector<double> >::fvcDdtPhiCorr(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) () from /home/santiago/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPDebug/libfiniteVolume.so

gdb is stopping indeed, but I can't go inside the method I want to go to:

(gdb) where
#0 0xb74c7c9b in Foam::fv::EulerDdtScheme<Foam::Vector<double> >::fvcDdtPhiCorr(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) () from /home/santiago/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPDebug/libfiniteVolume.so
#1 0x080eb875 in Foam::fvc::ddtPhiCorr<Foam::Vector<double> > (rA=..., rho=..., U=..., phi=...) at /home/santiago/OpenFOAM/OpenFOAM-1.6.x/src/finiteVolume/lnInclude/fvcDdt.C:147
#2 0x08091420 in main (argc=1474660693, argv=0xec815356) at pEqnParts.H:15

(gdb) down
Bottom (innermost) frame selected; you cannot go down.

Regards.