I'm having trouble with gdb and loading debugging information from shared libraries.
The error I get when running from within gdb is:
>>run
Error while mapping shared library sections: libhmmm.so: Success.
....
....
>>break container_main
Error cannot access memory at 0x9f18
The shared library in question exists and is located in the same directory, it contains debugging information and is not stripped.
The application works as expected.
When issuing info sharedlibrary from within gdb all shared libraries are listen but the from and to data is missing for the shared library in question.
Searched but haven't found any solution.
Googling turned up an old bug report and a forum discussion about some similar issue. If you are running GDB version < 6.1 then try upgrading to a newer version.
Related
I debugged an application using shared library on target linux system. And I came across the following errors:
(gdb) set sysroot /mnt/hgfs/sharefolders/mksdboot-tl/filesystem
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
(gdb)
Does the shared library have any problem or the GDB debugger is wrongly configured?
Any help would be great.
I am having trouble debugging when using gdbserver. gdb shows error loading one of the shared libraries.
Error while mapping shared library sections:
`target:<path to library>': not in executable format: Invalid argument
I have no problem when attaching with gdb using PID. But gdbserver throws the above error and then I am unable to set any breakpoints in that shared lib.
Any idea what could be wrong? I have other libraries from the same application that don't seem to have any problem.
I am running on
Centos 6.7
gdb version 7.11.1
gcc version 4.4.7
I encountered this error in GDB 7.11 (the one that ships with Android's NDK-r20), and it was caused by my library being relatively large (300MB), which tripped a bug in gdbserver's integer parser that prevented gdbserver from loading any library larger than 268MB. The bug got fixed in GDB 8.2, by raising the limit to 2GB (https://sourceware.org/bugzilla/show_bug.cgi?id=23198).
I used GDB's sysroot feature to work around this issue: https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#index-set-sysroot
I copied the libraries from the remote target to my local system* and used set sysroot sysroot-here (where "sysroot-here" is a directory containing the directories/files that I had copied). This forces GDB to read symbols locally instead of from the target.
With this sysroot approach, I did not only work around the bug, but I was also able to use the library with full debugging symbols (about 3GB, which would probably also have tripped newer GDB versions).
* I copied all system libraries and the app's libraries, while preserving the full directory structure / file paths. I wanted to only copy the specific library that triggered the bug, but with sysroot it is all or nothing: Either all libraries are to be found locally on the host, or none. See also: A way to have GDB load libraries from local sysroot and remote gdbserver
I found that gdb version 7.10+ has this problem with my particular binary. Still not sure why. This works fine with 7.9 so I downgraded to overcome this issue.
How can I get better error messages when developing shared libraries with ubuntu?
I'm developing a few shared objects to be loaded by our framework due to my inability to make everything 100% proof, sometimes external dependencies are added, which cannot be found when the library is loaded at runtime.
The error message for such things is something like: Cannot open shared object file: File or directory not found. What it REALLY is saying that something failed while loading the file.
Is there any way to make gdb spit out what actually was missing?
I used ldd to see if anything big was missing, but it said that everything is found.
I'm running gdb with set verbose on and I'm trying to understand one of the messages I am getting:
Reading symbols from system-supplied DSO at 0x7ffff7ffb000...(no debugging symbols found)...done.
What is thesystem-supplied DSO? After some search I think that DSO might stand for "dynamic shared object". But I still don't understand exactly what gdb is doing here and how I might solve the problem with the debugging symbols not being found (or if it even matters).
Also the program that I am debugging is being compiled with llvm-gcc and has an LLVM pass applied to it. I think that is effecting the behavior of gdb, but I"m not exactly sure how.
So essentially my question is what does the message that gdb prints mean, is it likely to cause a problem, and if so any suggestions on how I could help gdb find the debugging symbols.
According to this document a DSO is:
A dynamic shared object (DSO) is an object file that’s meant to be
used simultaneously— or shared—by multiple applications (a.out files)
while they’re executing.
I believe that a system supplied DSO is just a DLL provided by the OS and loaded by the main executable. Since this is an external library you don't have the debugging symbols of such object unless you download them separately. Typically the release binaries are stripped of debugging symbols but they can have a link to a separate file. A typical Linux distribution provides a package containing the debugging symbols of such binaries ( like the xxx-debuginfo-xxx.rpm for RedHat based distributions).
In this context, system-supplied-DSO means a shared library provided directly by the linux kernel such as VDSO. Debuginfo is indeed available for them, but is packaged along with the kernel rather than userspace. Use debuginfod to automatically fetch them if your distro supports that.
My application uses the Sun N1 grid engine through the API DRMAA present as shared object libdrmaa.so
.
I am using dlopen and dlsym to acess functions of the library. That works fine. Now if I try to link
it form command line the executable is built but executing it gives the error " Cannot open shared object file".
Can anyone suggest what may be the reason.
I am using g++ 2.95.3 for compilation and the machine is linux x86_64.
Thanx
Your question and answer are both very confused: if you can link your executable directly against libdrmaa.so, then there is absolutely no good reason to also dlopen that same library (and presumably call dlsym() on its handle as well).