Can gdb attach a zombie process(<defunct>)? - gdb

I have a program who run as zombie process. I want to debug it. But I got a gdb error.
mobile:/usr/local/ads5/bin# ps axf | grep ads_resolver
5583 pts/2 S 0:00 ./ads_resolver main.cfg
5584 pts/2 Zl 0:36 \_ [ads_resolver] <defunct>
mobile:/usr/local/ads5/bin# gdb ads_resolver 5584
GNU gdb 6.8-debian
Copyright (C) 2008 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 "i486-linux-gnu"...
Attaching to program: /usr/local/ads5/bin/ads_resolver, process 5584
ptrace: Operation not permitted.
/usr/local/ads5/bin/5584: No such file or directory.
(gdb) info threads
No registers.
There are my code that create the zombie process:
template < class T>
int Monitor < T >::Start()
{
pid_t pid;
pid = fork();
if(pid == 0)
{
IgnoreSignal::IgnoreDaemon();
signal(SIGCHLD,Monitor<T>::ReStart);
pid = fork();
if(pid == 0)
{
IgnoreSignal::IgnoreAll();
T worker;
worker.Run();
}
while(1)
{
sleep(60);
}
}
return 0;
}

A zombie process has completed execution but the operating system is waiting for the parent to call wait(). This is just a status or a flag - the process no longer "exists" in terms of being executable.
So no it would not be possible for gdb to connect to a process that is no longer executing including a zombie process.
http://en.wikipedia.org/wiki/Zombie_process

Related

My gdb debugger isn't responding when I launch it

I tried to setup the gdb debugger today which was already a hassle in itself. Now that it works (I can launch it at least) it gets stuck none of my commands have any effect on the debugger. I launch the debugger like so:
$ g++ main.cpp -g
$ gdb ./a.out
I can run layout next when I type run it just doesn't respond anymore.
I put an infinite loop in my program on purpose to see simulate a bug. Even without the loop its the exact same behavior.
It also doesn't say "done" when reading in the compiled file:
Now when I try to start gdb without any files specified. This is what happens:
➜ gdb
GNU gdb (GDB) 10.1
Copyright (C) 2020 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 "x86_64-apple-darwin20.1.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file ./a.out
Reading symbols from ./a.out...
Reading symbols from /Users/Documents/coding/C++/testing_c++/testing_c++/a.out.dSYM/Contents/Resources/DWARF/a.out...
../../gdb/thread.c:95: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
../../gdb/thread.c:95: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n

Remote debugging HiFive Unleashed in QEMU

I'm trying to get remote debugging working in QEMU for the sifive_u machine. All tools are from the Arch Linux repositories:
➜ qemu-system-riscv64 --version
QEMU emulator version 4.2.0
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
➜ riscv64-linux-gnu-gdb --version
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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.
I'm starting the machine as follows:
qemu-system-riscv64 -M sifive_u -m 256M -bios default -nographic -S -s
When I connect the debugger, I attempt to continue execution, but nothing happens; if I detach the debugger, the OpenSBI splash prints to the serial console. A typical gdb session looks something like this:
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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 "--host=x86_64-pc-linux-gnu --target=riscv64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000000000001000 in ?? ()
(gdb) info thread
Id Target Id Frame
* 1 Thread 1.1 (sifive-e51-riscv-cpu harts[0] [running]) 0x0000000000001000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000000080005a52 in ?? ()
(gdb) info thread
Id Target Id Frame
* 1 Thread 1.1 (sifive-e51-riscv-cpu harts[0] [halted ]) 0x0000000080005a52 in ?? ()
(gdb) detach
Detaching from program: , process 1
Ending remote debugging.
[Inferior 1 (process 1) detached]
It seems odd that I can only see a single thread in info thread; I would expect to see one thread per hart.
My hunch is that I end up attached to a hart which loses the lottery and goes to sleep, and for some none of the other harts are allowed to continue execution. If I use the virt machine, the execution starts as expected when I run continue and I see the OpenSBI splash immediately, so it seems to be linked to the use of the sifive_u in some way.
Does anyone have any idea what I'm doing wrong?
https://www.qemu.org/docs/master/system/gdb.html#Debugging%20multicore%20machines
See "Debugging multicore machines" in this page.
(gdb)target extended-remote :1234
(gdb)add-inferior
(gdb)inferior 2
(gdb)attach 2
(gdb)i threads
See this picture

schedBreak(<tick>) gdb debugging function not working

I am trying to create breakpoints and debug gem5 using gdb. I referred to http://www.gem5.org/Debugger_Based_Debugging.
As in the official documentation in the above link, I tried `call schedBreak() but it doesn't work. the following are the full commands:
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreak(10000)
warn: need to stop all queues
(gdb) c
Continuing.
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Aug 26 2019 20:59:02
gem5 started Sep 8 2019 15:17:55
gem5 executing on nirmal-cadsl2, pid 30158
command line: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7001
Beginning simulation!
info: Entering event queue # 0. Starting simulation...
Hello world!
Exiting # tick 501393000 because exiting with last active thread context
[Inferior 1 (process 30158) exited normally]
(gdb)
While this other tutorial http://gem5.org/wiki/images/0/0e/ASPLOS2017_gem5_tutorial.pdf (assuming the debug function is not particular to ISA) tells me that the function is actually schedBreakCycle(), it gives me this No symbol "schedBreakCycle" in current context. The full commands shown below.
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreakCycle(10000)
No symbol "schedBreakCycle" in current context.
(gdb)
gem5 version: ea8c435b6c6c092d72047eee50f125f5ae7347c3
gdb version: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Also, if I want to debug ALPHA or ARM full system on my ubuntu 18.04(x86), do I have to use any cross-compiled gdb versions or would native gdb suffice?
The tutorial is correct, you have to pass --debug-break to gem5:
gdb --args gem5.debug --debug-break=1000 ...
and then without breaking at main:
run
call schedBreak(5000)
continue
--debug-break generates a break at time 1000 and makes GDB stop there after main, and from that point, schedBreak does work.
Or alternatively first go to:
tbreak doSimLoop
run
call schedBreak(5000)
continue
schedBreak schedules an event in the event queue, which cannot be ready at main.
The breaks work by raising a signal, which GDB stops at by default.
ALPHA and ARM won't make a difference since schedBreak is a tiny helper to debug the host emulator itself, which is likely an x86 program. To debug the guest code, which is what most people want, see e.g. this tutorial.
Tested gem5 master at e87a293d1ffa6da38ba8fa145e7dc5128138ab77 in an X86 debug build.

gdb in emacs hangs when issuing the 'q(uit)' command

I'm using emacs 24.5.1 under Mac Yosemite, in graphical mode and I'm trying to get gdb 7.11 working.
After starting gdb with 'gdb', I use 'r' to run a mini C++ code, consisting only of an empty main(), which exits normally. After it exits I can type 'r' again and the program will run and exit fine again. However, when I type 'q' to quit gdb, I get a newline without the (gdb) prompt, but gdb does not seem to have quit; It no longer responds to input, but when I try invoking gdb again, emacs tells me that 'this program is already being debugged'.
Current directory is ~/cpp/ppcpp/
GNU gdb (GDB) 7.11
Copyright (C) 2016 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 "x86_64-apple-darwin15.4.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...Reading symbols from /Users/mwisse/cpp/ppcpp/a.out.dSYM/Contents/Resources/DWARF/a.out...done.
done.
(gdb) r
Starting program: /Users/mwisse/cpp/ppcpp/a.out
[Inferior 1 (process 98675) exited normally]
(gdb) r
Starting program: /Users/mwisse/cpp/ppcpp/a.out
[Inferior 1 (process 98677) exited normally]
(gdb) q
...This is me typing something to show I can type anything here...
but no response.
Has anyone seen this before?
I didn't find out what caused the issue, but it went away after replacing my .emacs.d directory with the one mentioned here: http://tuhdo.github.io/emacs-for-proglang.html.

On Raspberry Pi, cross compile helloworld in x86 with native gdb doesn't show source info

When I cross compile the helloworld code on x86 target raspberry pi, the pi's native gdb doesn't show the symbol info. Native pi's gcc works fine.
Cross compiler:
gcc version 4.8.3 20140106 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.01 - Linaro GCC 2013.11)
Native Compiler:
gcc version 4.6.3 (Debian 4.6.3-14+rpi1)
ls -al hellow*
-rw-rw-r-- 1 pi pi 81 Nov 16 18:54 hellow.c
-rwxrwxr-x 1 pi pi 7080 Nov 16 18:54 hellow_cross_compile
-rwxr-xr-x 1 pi pi 6529 Nov 16 18:57 hellow_native_compile
tlee#raspberrypi ~/mnt/u1404/k_pi/hellow $ gdb hellow_cross_compile
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 /home/tlee/mnt/u1404/k_pi/hellow/hellow_cross_compile...done.
(gdb) b main
Breakpoint 1 at 0x8414
(gdb) r
Starting program: /home/tlee/mnt/u1404/k_pi/hellow/hellow_cross_compile
Breakpoint 1, 0x00008414 in main ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 21284] will be killed.
Quit anyway? (y or n) y
tlee#raspberrypi ~/mnt/u1404/k_pi/hellow $ gdb ./hellow_native_compile
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 /home/tlee/mnt/u1404/k_pi/hellow/hellow_native_compile...done.
(gdb) b main
Breakpoint 1 at 0x83dc: file hellow.c, line 6.
(gdb) r
Starting program: /home/tlee/mnt/u1404/k_pi/hellow/hellow_native_compile
Breakpoint 1, main (argc=1, argv=0x7efff7e4) at hellow.c:6
6 printf("hellow\n");
(gdb) quit
A debugging session is active.
Inferior 1 [process 21307] will be killed.
Quit anyway? (y or n) y
Have anyone encounter this before? Any idea why and how to fix it?