Forum > Debugger
Trying to debug a shared library
c600g:
I've been working on a new shared library, and have developed an application which tests it. Is there any way to place a breakpoint in the shared library code and have Lazarus break when running the test application?
Here are some details:
* Both the shared library and app have been compiled in Debug mode with the default debug information included.
* In the shared library project, I've set the app as the host application, so that when I Run (F9) the project, the test app executes and everything works as expected.
* In the test app, I've tried both loading the shared library dynamically (using dynlibs), and just declaring the external function with no difference.
* I've also tried the "use launching application" Run Parameters... option, which doesn't work (gdb can't find "main" in context).I'm running Ubuntu 17.10 on x86_64. I've tried both the latest release of lazarus 1.8 / fpc 3.04 as well as trunk (using fpcupdeluxe) with the same results.
Thanks much for any ideas!
Martin_fr:
This is how it should work. (Have the library project open / Have the "host application" set).
Couple of points.
What happens to the breakpoints, do they turn orange (in the gutter / breakpoint window)?
Or do they stay red?
---------------------
Breakpoints work by unit name only, so if both (lib & host) have a unit1.pas, then there is a problem setting breakpoints.
Either make sure unit name are unique, or compile the host without debug.
Also, while it should work when the host has debug info, there is one limitations. If the host has debug info, exceptions in the lib will not be seen by the debugger. But that should not affect your breakpoints.
Debugging exceptions also only work for static linked dll.
But other than exception, I recently tried this on Fedora with success. (small sample project only)
-------------
How do you make your library available? Do you provide an LD_LIBRARY_PATH? Or do you copy it into libs folder? Are you sure the correct one is loaded?
---------------------
"launching app" should be empty.
If it is not any of the above, can you create a log file:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session
c600g:
Martin,
Thanks much for the response.
--- Quote from: Martin_fr on January 22, 2018, 04:11:45 am ---This is how it should work. (Have the library project open / Have the "host application" set).
--- End quote ---
Done.
--- Quote from: Martin_fr on January 22, 2018, 04:11:45 am ---What happens to the breakpoints, do they turn orange (in the gutter / breakpoint window)?
Or do they stay red?
--- End quote ---
When I set a breakpoint in the library, a red circle with a question mark appears in the gutter. When I execute the project (F9), the host application starts up and the gutter breakpoint symbol changes into a red circle with a green checkmark.
--- Quote from: Martin_fr on January 22, 2018, 04:11:45 am ---Breakpoints work by unit name only, so if both (lib & host) have a unit1.pas, then there is a problem setting breakpoints.
Either make sure unit name are unique, or compile the host without debug.
--- End quote ---
Not an issue here, as the unit has a unique name.
--- Quote from: Martin_fr on January 22, 2018, 04:11:45 am ---Also, while it should work when the host has debug info, there is one limitations. If the host has debug info, exceptions in the lib will not be seen by the debugger. But that should not affect your breakpoints.
Debugging exceptions also only work for static linked dll.
--- End quote ---
Good to know.
--- Quote from: Martin_fr on January 22, 2018, 04:11:45 am ---How do you make your library available? Do you provide an LD_LIBRARY_PATH? Or do you copy it into libs folder? Are you sure the correct one is loaded?
--- End quote ---
I set up a symbolic link in /usr/lib that points to the compiled library. Should I instead set "LD_LIBRARY_PATH=." ?
--- Quote from: Martin_fr on January 22, 2018, 04:11:45 am ---"launching app" should be empty.
--- End quote ---
Confirmed.
When the test application is compiled, a .dbg file is also created with it (containing debug information, I assume). However, when the library is compiled, there isn't a corresponding .dbg file. Is this normal?
--- Quote from: Martin_fr on January 22, 2018, 04:11:45 am ---If it is not any of the above, can you create a log file:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session
--- End quote ---
Debug log attached.
Thanks again,
Alan
c600g:
Looking at the debug output (View -> Debug Windows -> Debug Output), I see this as the likely problem:
--- Code: ---<-symbol-list-lines "/home/alank/work/sce/JSON/module/module_hpml.pas">
^error,msg="-symbol-list-lines: Unknown source file name."
--- End code ---
Alan
Martin_fr:
The "unknown source" is correct. At that time the source is not yet known. It becomes known when your lib is loaded, and gdb will then update the breakpoint.
Only:
--- Quote ---TCmdLineDebugger.ReadLn "=library-loaded,id="/usr/lib/libscejson.so",target-name="/usr/lib/libscejson.so",host-name="/usr/lib/libscejson.so",symbols-loaded="0",thread-group="i1""
--- End quote ---
It does not become known. Because gdb does not find your debug info.
Since you have a .dbg file you use external debug info. I never tested this, but it still could work.
I assume at this point, that gdb looks for it in
/usr/lib/libscejson.dbg
But since your lib is a link, the dbg file is not there?
Various solutions to try:
1) ensure the dbg file can be found
2) switch off external debug info
3) use LD_LIBRARY_PATH (and remove the symlink)
I recommend 3.
Because you can test your lib, without interfering with your real libs.
Just go to run params, and set it as env var. pointing to where your lib is.
-----------
When you try to fix it, watch the logfile, and see if gdb does load any symbols.
-------------
Also check your global options, and check that the following is NOT set
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#SigSegV_-_and_continue_debugging
Though according to the log, it is not set. So should already be ok.
Navigation
[0] Message Index
[#] Next page