The issue is simple. I have my plugin created by Firebreath and would like to debug my *API.cpp file using gdb in Linux.
Yes, i already read this article, and i got this PID:
30227 0.0 0.4 115024 12300 pts/2 Sl+ 00:03 0:00 /usr/lib/chromium/chromium --type=plugin --plugin-path=/home/USER/Documents/mycode/0.1/npMyPlugin.so
When i opened with gdb i always get a similar output like this:
Reading symbols from /usr/lib/libpcrecpp.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libpcrecpp.so.0
Reading symbols from /usr/lib/libssh2.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssh2.so.1
Reading symbols from /usr/lib/libssl.so.1.0.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssl.so.1.0.0
Reading symbols from /usr/lib/libcrypto.so.1.0.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcrypto.so.1.0.0
Probably not the right process. Any idea?
Thanks in advanced.
Update - Ignoring the message
Thanks guys for your comments. Well i ignored the message and did the following:
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n)
Program not restarted.
(gdb) b 328
No line 328 in the current file.
Make breakpoint pending on future shared library load? (y or n)
So basically gdb load my MyPlugin.cpp and not my MyPluginAPI.cpp. Any idea?
Setting a break point with just a line-number only works if you have exactly one source file.
Use e.g. b MyPluginAPI.cpp:328 or b MyPluginAPI::myMethod() instead.
Related
i have trouble with vsc.
#include<stdio.h>
int main ()
{
int a;
printf("Hello World ");
scanf("%d", &a)
printf("%d", a);
return 0;
}
this is my code. & This is Debug Console.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"
=cmd-param-changed,param="args",value="2>CON 1>CON <CON"
[New Thread 13300.0x59d4]
[New Thread 13300.0x367c]
Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Symbols loaded.
Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Symbols loaded.
Loaded 'C:\Windows\SysWOW64\msvcrt.dll'. Symbols loaded
When i try to run, it does not start.
I already installed coderunner.
Please help thx.
What exactly do you mean by running it? Your code looks ok, so I'm guessing you are just doing something wrong when you try to run it.
Firstly, you need to compile your code, and then you can run the program that is created after compilation.
The simplest way to compile both c and c++ is to use console and gcc. Try entering this command in the terminal:
gcc -Wall -fsanitize=address,undefined -o yourprogram yourprogram.c
This should create yourprogram file in the directory you are in. To run it, pass this command in the console:
./yourprogram
For example, if we do
mkdir a
mkdir a/b
mkdir a/b/c
mkdir a/b/c/d
ln /bin/ls -s a/b/c/d/myls
ln a -s as
gdb as/b/c/d/myls
...
(gdb) r
Starting program: <mypath>/a/b/c/d/myls
^D
lldb as/b/c/d/myls
(lldb) r
Process 56636 launched: '<mypath>/as/b/c/d/myls' (x86_64)
We can see that gdb debugs on the canonical program, while lldb debugs on the linked program. How can we make gdb debug the linked program w/o getting its absolute path?
We can see that gdb debugs on the canonical program, while lldb debugs on the linked program.
No, we don't see this. We see that GDB performs a realpath to resolve the program, and lldb doesn't, but they both debug the exact same program.
Maybe you can use hard links instead?
This way, gdb will always refer to what you are looking for.
You can also play with with different version of gdb. It seems that version 7.11 provides what you want.
Take a look here:
~/tmp/link] stat hello
File: ‘hello’ -> ‘../hello’
This is what you get for version 7.12
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./link/hello...(no debugging symbols found)...done.
while for older gdb, you get
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from full_path/tmp/hello...(no debugging symbols found)...done.
So, play around with more recent release.
I have a C++ program that receives streaming music and plays it. I can run the program via the shell and run with it attached and it runs completely fine. I can stream audio to it and send things to it, but it will not crash. However, when I daemonize it and run the fork code, it will crash unexpectedly after a little bit of streaming. I try to use gdb to debug it, but it doesn't give much output.
./bin/sonar -d ; sleep 1 ; gdb ./bin/sonar $(cat sonar.pid )
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /var/sonar/bin/sonar...done.
Attaching to program: /var/sonar/bin/sonar, process 4050
Reading symbols from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
Reading symbols from /var/sonar/bin/../lib/libboost_system.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_system.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_chrono.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_chrono.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_timer.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_timer.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_iostreams.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_iostreams.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_thread.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_thread.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_log_setup.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_log_setup.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_log.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_log.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_filesystem.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_filesystem.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_atomic.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_atomic.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_date_time.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_date_time.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libboost_regex.so.1.60.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libboost_regex.so.1.60.0
Reading symbols from /var/sonar/bin/../lib/libopus.so.0...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libopus.so.0
Reading symbols from /var/sonar/bin/../lib/libmysql.so.16...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libmysql.so.16
Reading symbols from /var/sonar/bin/../lib/libmysqlpp.so.3...(no debugging symbols found)...done.
Loaded symbols for /var/sonar/bin/../lib/libmysqlpp.so.3
Reading symbols from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
Reading symbols from /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0
Reading symbols from /usr/lib/arm-linux-gnueabihf/libasound.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libasound.so.2
Reading symbols from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Reading symbols from /lib/arm-linux-gnueabihf/libm.so.6...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libm-2.19.so...done.
done.
Loaded symbols for /lib/arm-linux-gnueabihf/libm.so.6
Reading symbols from /lib/arm-linux-gnueabihf/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/arm-linux-gnueabihf/libgcc_s.so.1
Reading symbols from /lib/arm-linux-gnueabihf/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libpthread-2.19.so...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x749ff450 (LWP 4054)]
[New Thread 0x75358450 (LWP 4053)]
[New Thread 0x75b58450 (LWP 4052)]
done.
Loaded symbols for /lib/arm-linux-gnueabihf/libpthread.so.0
Reading symbols from /lib/arm-linux-gnueabihf/libc.so.6...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libc-2.19.so...done.
done.
Loaded symbols for /lib/arm-linux-gnueabihf/libc.so.6
Reading symbols from /lib/arm-linux-gnueabihf/librt.so.1...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/librt-2.19.so...done.
done.
Loaded symbols for /lib/arm-linux-gnueabihf/librt.so.1
Reading symbols from /lib/arm-linux-gnueabihf/libbz2.so.1.0...(no debugging symbols found)...done.
Loaded symbols for /lib/arm-linux-gnueabihf/libbz2.so.1.0
Reading symbols from /lib/arm-linux-gnueabihf/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/arm-linux-gnueabihf/libz.so.1
Reading symbols from /lib/arm-linux-gnueabihf/libdl.so.2...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libdl-2.19.so...done.
done.
Loaded symbols for /lib/arm-linux-gnueabihf/libdl.so.2
Reading symbols from /lib/ld-linux-armhf.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux-armhf.so.3
Reading symbols from /lib/arm-linux-gnueabihf/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libnss_files-2.19.so...done.
done.
Loaded symbols for /lib/arm-linux-gnueabihf/libnss_files.so.2
0x763e1d14 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) c
Continuing.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x75358450 (LWP 4053)]
0x7633df70 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0 0x7633df70 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0x7633f324 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0x7656eb5c in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3 0x7656c9a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#4 0x7656c9a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) c
Continuing.
[Thread 0x762ac000 (LWP 4050) exited]
[Thread 0x75b58450 (LWP 4052) exited]
[Thread 0x749ff450 (LWP 4054) exited]
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb)
The daemonizing code that I use:
// Daemonize
LOG_INFO( *logger ) << "Daemonizing.";
// Sig stuff
pid_t pid, sid;
// Start the forky pig
if( (pid = fork())<0 )
{
LOG_ERROR( *logger ) << "Error forking: " << strerror( errno );
return( EXIT_FAILURE );
}
// The parent can go home
if( pid>0 )
return( EXIT_SUCCESS );
// Make ourselves emancipate
if( (sid = setsid())<0 )
{
LOG_ERROR( *logger ) << "setsid error: " << strerror( errno );
return( EXIT_FAILURE );
}
// Ignore sigpipes
signal( SIGPIPE, SIG_IGN );
// Close the file descriptors to detach
close( STDIN_FILENO );
close( STDOUT_FILENO );
close( STDERR_FILENO );
If the program works when it's not daemonized and crashes when it is, there is obviously some difference in the way that it runs. So my question really is, where can I look for this particular point of failure?
Here is the same error on a 64-bit intel arch processor:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f80777b8700 (LWP 10314)]
0x00007f807baa7297 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
55 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f807baa7297 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007f807baa862a in __GI_abort () at abort.c:89
#2 0x00007f807c5a700d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#3 0x00007f807c5a4e96 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#4 0x00007f807c5a4ee1 in std::terminate() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#5 0x00007f807c600c21 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#6 0x00007f807be16324 in start_thread (arg=0x7f80777b8700) at pthread_create.c:333
#7 0x00007f807bb5bf6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
there is a difference in running a process in an interactive environment or as a daemon. When you run a process from the command line, then the process is inheriting all resources from the interactive environment like Paths, defined in environment PATH variables, or even the working directory, which is, in an interactive environment, the actual directory from where a process is started.
Without knowing your system or environment, one of the mistakes which are often done is trying to start background process, daemons, for example from a crontab, but to forget to give the information a process needs to work. When a process is running as a daemon, without knowing the circumstances of your work flow, for example, it i necessary to give the process the environment, to mention one, the working directory. I do it for example with "chdir("/");", so the forked child will know, on what working directory he is active.
Depending on your other resources, you should give the daemon all the information, it needs to fulfil its job, e.g. if it starts some process, for example the PATH to the process and so on.
regards
Turns out that it was a log file crash. I wasn't seeing the throw error because the error was with the logging system itself. Since all of the ties to stdout were cut, nothing was being displayed. It was exactly the issue in this post with Boost.Log:
Boost Log causes crash when trying first log statement (when not Administrator)
I have a program that crashed on RHEL 6.5, also I have a coredump file.
I want to debug it on RHEL 6.4, but it has another version of glibc. I put glibc.so.6 from RHEL 6.5 to lib/ directory, but can't set gdb up to use it:
[nskdvlp#srv2-csd-mong01 snmp_int]$ LD_LIBRARY_PATH=/u01/app/maa/snmp_int/lib gdb bin/snmp_int
Reading symbols from /u01/app/maa/snmp_int/bin/snmp_int...done.
(gdb) info sharedlibrary
No shared libraries loaded at this time.
(gdb) set solib-search-path lib
warning: .dynamic section for "/lib64/libc.so.6" is not at the expected address (wrong library or version mismatch?)
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /u01/app/maa/snmp_int/lib/libsnmp_int_snmp.so.6.0.5...done.
Loaded symbols for /u01/app/maa/snmp_int/lib/libsnmp_int_snmp.so.6.0.5
(gdb) core core.110358
[New Thread 110358]
[New Thread 110367]
warning: .dynamic section for "/lib64/libc.so.6" is not at the expected address (wrong library or version mismatch?)
warning: Could not load shared library symbols for (0x%0*Zx)
.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
(gdb) bt
#0 0x0000003e93a32925 in ?? ()
#1 0x0000003e93a3408d in ?? ()
#2 0x0000000000000000 in ?? ()
Other .so libraries are loaded well from lib/
I put glibc.so.6 from RHEL 6.5 to lib/ directory, but can't set gdb up to use it:
There is no such thing as glibc.so.6. You mean libc.so.6.
This is nowhere near sufficient: you need all libraries and the dynamic loader from the system on which the core was produced. See this answer for what you need to do.
I've configure all CONFIG_DEBUG_ related options to y,but when I try to debug the kernel,it says no debug symbols found:
gdb /usr/src/linux-2.6.32.9/vmlinux /proc/kcore
Reading symbols from /usr/src/linux-2.6.32.9/vmlinux...(no debugging symbols found)...done.
Why?
Here is my best guess so far: I don't know, and it doesn't matter.
I don't know why GDB is printing the message "(no debugging symbols found)". I've actually seen this when building my own kernels. I configure a kernel to use debug symbols, but GDB still prints this message when it looks at the kernel image. I never bothered to look into it, because my image can still be debugged fine. Despite the message, GDB can still disassemble functions, add breakpoints, look up symbols, and single-step through functions. I never noticed a lack of debugging functionality. I'm guessing that the same thing is happening to you.
Edit: Based on the your comments to the question, it looks like you were searching for the wrong symbol with your debugger. System call handlers start with a prefix of sys_, but you can't tell from looking at the code. The macro SYSCALL_DEFINE4(ptrace, ...) just ends up declaring the function as asmlinkage long sys_ptrace(...), although it does some other crazy stuff if you have ftrace enabled.
make menuconfig->kernel hacking->[]Kernel debugging->[]Compile the kernel with debug info(CONFIG_DEBUG_INFO)
It's also possible when you package your vmlinuz image, the debug symbols were stripped (when using make-kpkg to build deb package for linux kernel). So you have to use the built vmlinux file under your linux source tree to have those debug symbols.
Add -g to the CFLAGS variable in the kernel Makefile
I might be wrong, but I thought you would have to install the debuginfo package for your kernel to get symbols