|
[Sponsors] |
May 18, 2011, 10:54 |
Debugging within libfiniteVolume.so
|
#1 |
Senior Member
Santiago Marquez Damian
Join Date: Aug 2009
Location: Santa Fe, Santa Fe, Argentina
Posts: 452
Rep Power: 23 |
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.
__________________
Santiago MÁRQUEZ DAMIÁN, Ph.D. Research Scientist Research Center for Computational Methods (CIMEC) - CONICET/UNL Tel: 54-342-4511594 Int. 7032 Colectora Ruta Nac. 168 / Paraje El Pozo (3000) Santa Fe - Argentina. http://www.cimec.org.ar |
|
May 19, 2011, 04:26 |
|
#2 |
Senior Member
Gijsbert Wierink
Join Date: Mar 2009
Posts: 383
Rep Power: 18 |
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: Code:
c++OPT = -O3
__________________
Regards, Gijs |
|
May 19, 2011, 08:52 |
|
#3 |
Senior Member
Anton Kidess
Join Date: May 2009
Location: Germany
Posts: 1,377
Rep Power: 29 |
Gijsbert, WM_COMPILE_OPTION=Debug already disables optimization I believe.
|
|
May 19, 2011, 17:06 |
|
#4 |
Senior Member
Santiago Marquez Damian
Join Date: Aug 2009
Location: Santa Fe, Santa Fe, Argentina
Posts: 452
Rep Power: 23 |
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.
__________________
Santiago MÁRQUEZ DAMIÁN, Ph.D. Research Scientist Research Center for Computational Methods (CIMEC) - CONICET/UNL Tel: 54-342-4511594 Int. 7032 Colectora Ruta Nac. 168 / Paraje El Pozo (3000) Santa Fe - Argentina. http://www.cimec.org.ar |
|
May 20, 2011, 00:20 |
|
#5 | |
Senior Member
Gijsbert Wierink
Join Date: Mar 2009
Posts: 383
Rep Power: 18 |
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 ... Quote:
__________________
Regards, Gijs |
||
May 20, 2011, 08:44 |
|
#6 |
Senior Member
Santiago Marquez Damian
Join Date: Aug 2009
Location: Santa Fe, Santa Fe, Argentina
Posts: 452
Rep Power: 23 |
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.
__________________
Santiago MÁRQUEZ DAMIÁN, Ph.D. Research Scientist Research Center for Computational Methods (CIMEC) - CONICET/UNL Tel: 54-342-4511594 Int. 7032 Colectora Ruta Nac. 168 / Paraje El Pozo (3000) Santa Fe - Argentina. http://www.cimec.org.ar |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
On debugging a Womersley Profile UDF | david | FLUENT | 3 | August 7, 2017 03:49 |
Debugging Unsteady 2-D Panel Method Code: Wake Modeling | RajeshAero | Main CFD Forum | 5 | November 10, 2011 05:48 |
help debugging Beam deflection UDF | josik_1982 | Fluent UDF and Scheme Programming | 0 | December 19, 2010 17:36 |
Debugging a segmentation fault? | hansel | OpenFOAM Bugs | 3 | July 31, 2010 13:13 |
Debugging Udfs in Fluent 5.x | Greg Perkins | FLUENT | 0 | April 2, 2001 03:03 |