Debug symbols missing in compiled TMAP8 - breakpoints point to system headers instead of source code

[yangmingrui96]

Description:

Hello,

I'm trying to compile and debug TMAP8 following the official installation guide at: https://mooseframework.inl.gov/TMAP8/getting_started/installation.html

I've successfully compiled the program using METHOD=dbg, but I'm having trouble setting breakpoints in the TMAP8 source code during debugging.

Problem: When I try to set a breakpoint at main in GDB, it points to a system header file instead of the actual TMAP8 source:

(gdb) break main
Breakpoint 1 at 0x7519: file /home/user1/miniforge3/envs/moose/libmesh/include/Eigen/src/Core/util/MooseApp.h, line 15.

The output from info sources shows that the debug information seems to be pointing to Conda environment paths and system headers, but not to my actual TMAP8 source code:

/home/user1/project/TMAP8/main.C,
/home/user1/miniforge3/envs/moose/lib/gcc/x86_64-conda-linux-gnu/12.3.0/include/c++/x86_64-conda-linux-gnu/bits/typeinfo,
/home/user1/miniforge3/envs/moose/lib/gcc/x86_64-conda-linux-gnu/12.3.0/include/c++/x86_64-conda-linux-gnu/bits/new,
... (many more system/Conda paths)

What I've tried:
Compiled with make METHOD=dbg
Checked that the executable (tmap8-dbg) exists and runs correctly
Verified that the shared libraries (including libtmap8-dbg.so) are present
Tried attaching to the running process instead of launching directly

Environment:
OS: Linux
Conda environment: moose
Compiler: gcc/g++ from Conda environment
MOOSE/TMAP8: Latest from repository

Questions:
Why does the debug information point to system headers instead of my source code?
How can I ensure that the compiled TMAP8 includes proper debug symbols for my source files?
Is there a specific build configuration needed for source-level debugging?

[cticenhour]

Hello, thanks for your question!

First off, I want to direct your attention to the MOOSE debugging documentation, which will be relevant for TMAP8 as well: https://mooseframework.inl.gov/application_development/debugging.html

I am unsure exactly why GDB pointed to that particular location compared to any other (in fact, that header path doesn't really make sense to me.....a MooseApp.h doesn't exist in Eigen). I imagine this is something to do with the conda-based portability changes made to these libraries and headers when the conda package is built. You might ask - why didn't it just go to TMAP8's main() function? Well, that might be related to some of the abstraction we do around MooseApp itself. TMAP8's main() doesn't actually have that much in it!

You'll see in the documentation I linked above that the tmap8-dbg executable has all the symbols you need to debug properly. You might just need to change your approach. When debugging degmentation faults, for example, I often set a breakpoint for MPI_Abort, but there are lots of other options too. Some new documentation on the MOOSE side for this is actually being added right now in idaholab/moose#32278, but I will quote the relevant bits here:

In addition to MPI_Abort, some other useful breakpoints are

• PetscError for errors reported by PETSc
• TIMPI:report_error for errors reported by TIMPI
• libMesh::MacroFunctions::report_error for errors reported by libMesh

In addition, you should have access to symbols for particular methods, like ADMatInterfaceReactionYHxPCT::computeQpResidual in ADMatInterfaceReactionYHxPCT.C by using the

b ADMatInterfaceReactionYHxPCT::computeQpResidual

syntax. That is, if I am remembering correctly what is available to you at a class level. You should be able to start typing a class name and use tab-completion to see what might be available for setting breakpoints.

Hope this helps! Let me know if you have further questions.

[simopier]

@yangmingrui96 let us know if this is still an issue. In the meantime, I'll mark @cticenhour's response as an answer.