i had a problem in my native android application saying libc: Fatal signal 7 (SIGBUS) at 0x66f0001d (code=1), thread 30165 (xample.fft_test)
which i think is a memory problem on the device(nexus 4).
So, i tried to debug the application to know the source of this problem.
In eclipse, i get warning: Could not load shared library symbols for 94 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find dynamic linker breakpoint function.
GDB will retry eventurally. Meanwhile, it is likely
that GDB is unable to debug shared library initializers
or resolve pending breakpoints after dlopen().
what does that mean?
here's also the output of the allocation tracker in eclipse:
If your application.mk has flags:
APP_STL := gnustl_static
APP_OPTIM := debug
You have a problem with the compilation´s flags.
The warning means those libraries have not compiled with debug flags, and then, you have not debug info so you cannot debug. Maybe you can stop in breakpoints and follow step by step, but you cannot read in real time the value of the variables.
So, to solve the problem, you must re-compile the libraries that you want to read variables with debug information flags. In Cmake I usually use flag -d or -gdwarf-4 to crosscompile in Android.
I had the same issue and I solved it by using another phone.
I tested on a lot of phones. Finally, I find out that debug NDK on Nexus 6 is ok.
So I think maybe the issue is that the support for debugging NDK was removed on some phones.
Related
I realize a question with the exact title has already been answered, but the steps there requires running the compiler and linker manually, whereas I want to use cmake.
I am trying to debug a C program with WinDbg. But I'm getting this error:
*** WARNING: Unable to verify checksum for main.exe
Reading a mailing list thread1, I'm guessing I need to add a few flags, namely '/Zi' and '/Release'. But I'm building my project with cmake, and I don't know how to add those flags properly so that I can build my program using GNU toolchain with debug symbols too.
My CMakeLists.txt:
cmake_minimum_required(VERSION 3.00)
project(Hello LANGUAGES C)
add_executable(main src/main.c)
With the above cmake file, my program is built properly. Even a pdb file is generated, which is read by WinDbg no problem. But I can't see the line information with .lines and no source file is shown when debugging the EXE; only assembly commands are shown.
After the reading the mail thread (mentioned above), I checked the checksum value of my EXE. It's zero. Now I need to know how to set up a cmake file so it produces EXE with debug symbols with proper checksum.
The checksum-verification warning turned out not to be the issue (it was just a warning after all, not an error). WinDbg didn't load line information. Either it's the default (although I don't know why that would be) or I mistakenly turned it off myself. Whatever the case, here is how you turn it on:
.lines -e
After that, WinDbg was able to bring up the source window by its own accord when I started debugging.
When I attach to process with GDB I saw that warning:
Reading symbols from /CloneFileSystem/lib/ld-uClibc.so.0...
(No debugging symbols found in /CloneFileSystem/lib/ld-uClibc.so.0)
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Even I use set sysroot /CloneFileSystem with all the libraries there, that not help.
My process call to function in shared library and that function call to another function in another shared library.
For example ProcessFunc-> Lib1Func -> Lib2Func
I want to debug Lib2Func but when I run command
b Lib2Func
gdb can't set a breakpoint there event that library is already loaded
file myexe -> interpreter /lib/ld-uClibc.so.0
When I use info sharedlibrary in GDB I can't the value in From and To (address of loaded are empty)
You might want to try recompiling the library with a -g option. It's saying it can't find the debug info. -g provides for debugging info if you are using gcc. This is the first thing i'd check. If the library is big this may take awhile.
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
I want to debug pthreads on my custom linux distribution but I am missing something. My host is Ubuntu 12.04, my target is an i486 custom embedded Linux built with a crosstool-NG cross compiler toolset, the rest of the OS is made with Buildroot.
I will list the facts:
I can run multi-threaded applications on my target
Google Breakpad fails to create a crash report when I run a multi-threaded application on the target. The exact same application with the exact same build of Breakpad libraries will succeed when I run it on my host.
GDB fails to debug multithreaded applications on my target.
e.g.
$./gdb -n -ex "thread apply all backtrace" ./a.out --pid 716
dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads.
GNU gdb 6.8
I don't think ps_lgetfpregs is a problem because of this.
My crosstool build created the libthread_db.so file, and I put it on the target.
My crosstool build created the gdb for my target, so it should have been linked against the same libraries that I run on the target.
If I run gdb on my host, against my test app, I get a backtrace of each running thread.
I suspect the problem with Breakpad is related to the problem with GDB, but I cannot substantiate this. The only commonality is lack of multithreaded debug.
There is some crucial difference between my host and target that stops me from being able to debug pthreads on the target.
Does anyone know what it is?
EDIT:
Denys Dmytriyenko from TI says:
Normally, GDB is not very picky and you can mix and match different
versions of gdb and gdbserver. But, unfortunately, if you need to
debug multi-threaded apps, there are some dependencies for specific
APIs...
For example, this is one of the messages you may see if you didn't
build GDB properly for the thread support:
dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1:
undefined symbol: ps_lgetfpregs GDB will not be able to debug
pthreads.
Note that this error is the same as the one that I get but he doesn't go in to detail about how to build GDB "properly".
and the GDB FAQ says:
(Q) GDB does not see any threads besides the one in which crash occurred;
or SIGTRAP kills my program when I set a breakpoint.
(A) This frequently
happen on Linux, especially on embedded targets. There are two common
causes:
you are using glibc, and you have stripped libpthread.so.0
mismatch between libpthread.so.0 and libthread_db.so.1
GDB itself does
not know how to decode "thread control blocks" maintained by glibc and
considered to be glibc private implementation detail. It uses
libthread_db.so.1 (part of glibc) to help it do so. Therefore,
libthread_db.so.1 and libpthread.so.0 must match in version and
compilation flags. In addition, libthread_db.so.1 requires certain
non-global symbols to be present in libpthread.so.0.
Solution: use
strip --strip-debug libpthread.so.0 instead of strip libpthread.so.0.
I tried a non-stripped libpthread.so.0 but it didn't make a difference. I will investigate any mismatch between pthread and thread_db.
This:
dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads.
means that the libthread_db.so.1 library was not able to find the symbol ps_lgetfpregs in gdb.
Why?
Because I built gdb using Crosstoolg-NG with the "Build a static native gdb" option and this adds the -static option to gcc.
The native gdb is built with the -rdynamic option and this populates the .dynsym symbol table in the ELF file with all symbols, even unused ones. libread_db uses this symbol table to find ps_lgetfpregs from gdb.
But -static strips the .dynsym table from the ELF file.
At this point there are two options:
Don't build a static native gdb if you want to debug threads.
Build a static gdb and a static libthread_db (not tested)
Edit:
By the way, this does not explain why Breakpad in unable to debug multithreaded applications on my target.
Just a though... To use the gdb debugger, you need to compile your code with -g option. For instance, gcc -g -c *.c.
I get the following message in gdb (version 7.1):
[Thread debugging using libthread_db enabled]
and the command reverse-step
results with the following error message:
(gdb) reverse-step
Target multi-thread does not support this command
I am debugging a serial code right now, so I definitely do not need multi-threading. Can I turn this off somehow so that I get the latest reverse-debug commands to work? Also, if the code is parallelised with OpenMPI, there will be no need for multi-thread debugging at all, right?
Edit: Is this set as a compilation flag that can be just excluded?
You don't mention which version of GDB you're using, but since a little while, the parameter libthread-db-search-path is available.
(gdb) set libthread-db-search-path /tmp
(gdb) start
Temporary breakpoint 1 at 0x400632: file threads.c, line 14.
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
will tell GDB to lookup it's helper library (libthread-db.so) in a directory where it isn't, so multithread debugging won't be enabled!
I'm not sure about OpenMPI parallel applications are multiprocesses (in contrast with OpenMP where they are multithreaded), so it won't change anything for you.
EDIT: Multithread debugging is usually only enabled when libpthread.so or equivalent is loaded by your process (ldd your-process to check if it's linked as a shared library) so if you don't need it, there might be a problem in your compilation script.