1

I have a python executable: pyExec.py. This program utilizes a C/C++ shared library: abc.so. This abc library requires another C/C++ library: xyz. Once xyz is built, it generates multiple static library files and one shared library file, which are then used to build abc. I want to investigate a function ffn which is present in one of the source files for xyz.

None of these libraries throw any error during the compilation. The error I am investigating occurs when I run a particular function in pyExec.py. So far, this error has been traced back to ffn. However, to proceed further, I would like to use a debugger.

I tried this answer, along with a few variants of it. I tried setting break points in the source files of both xyz and abc using both line numbers and function names, just to test things out. The debugger, gdb, does ask if the break point is pending on a future shared library load to which I answer yes. But unfortunately the break point is ignored when I run the (python) program. The debugger is called as shown here.

  1. Is gdb the best tool for such an investigation?
  2. What could be the best overall approach in this context?
  3. Can static libraries be investigated with this approach?
skr
  • 914
  • 3
  • 18
  • 35
  • The best tool is carefully designed unit tests for the libraries in question, even if they are written in that nonexistent "C/C++" language. – Pete Becker Aug 17 '22 at 19:02

1 Answers1

1

  1. gdb should be very capable but you need to be aware of versions. I was recently using clang to compile and gdb to debug and hit this exact case. Ends up clang supports more debug formats. When I switched to lldb (clang's debugger) all symbols came clean. Try lldb and see what happens.

  2. Unit tests. They help set up edge cases. Try to eliminate all the environment complexity and isolate in the smallest reproducible example you can.

  3. Yes, absolutely. You need to be sure you are compiling with debug information though.

Something Something
  • 3,999
  • 1
  • 6
  • 21
  • Assuming the libraries are your own : I would go for option 2, that way you know the combination) of libraries work and that any issue you see after that is due to integration with python. – Pepijn Kramer Aug 17 '22 at 16:52
  • @PepijnKramer Well debugging inside a library you do not own is a lost cause right? – Something Something Aug 17 '22 at 17:06
  • I do have the source files of the libraries. But both libraries came from elsewhere. The python executable is mine. The libraries are mostly meant for windows (I am on linux). The library `xyz` is extensive and really old - with outdated facilities. But I will try option 2. – skr Aug 17 '22 at 17:07
  • @skr the C language is 50 years old and barely unchanged. Still, +80% of packages in any Linux distro are written in C. Old is good when the design is good. – Something Something Aug 17 '22 at 17:52
  • 1
    @MadFred Not always, when it is a header file only library or you have the sources. I've done that often. – Pepijn Kramer Aug 17 '22 at 17:58
  • Maybe by unit testing you can find a (corner) case that mimmicks your problem, then at least you can isolate it a bit more. – Pepijn Kramer Aug 17 '22 at 17:58