I am attaching a running process in linux platform using gdb.
gdb -p <pid>
Setting the breakpoint, say
b test.cpp : 23
Now continuing
c
After this when i perform some operation destined to attached process, getting the below error in gdb console:
(gdb) c
Continuing.
[New Thread 0x7409fb70 (LWP 8530)]
Cannot get thread event message: debugger service failed
Please help me how to proceed further.
Additional details:
Its icc compiler, compiling with -g flag enabled
Related
Ubuntu 16.04.4 LTS, GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
I am trying to call a function in a compiled C program and get the following:
"(gdb) call getVarName(someParam)
You can't do that without a process to debug."
There are no other codes or messages.
I can run the program from the shell prompt
jef#ubuntu$ ./program.
I can run the program within gdb after designating the file. Permissions are 777 (just to cover all bases).
Based on research, I set the SHELL with "export SHELL=/bin/bash"
and
set kernal.yama.ptrace_scope = 0 in /etc/sysctl.d/10-ptrace.conf
I still get the same behavior.
I still get the same behavior.
Naturally.
The error you are getting means: you can't do this, unless you are debugging a live process.
This will work:
(gdb) break main
(gdb) run
... GDB is now stopped, *and* you have a live process.
... you *can* call getVarName(...) now
(gdb) call getVarName(...)
(gdb) continue # causes the process to run to end and exit
[Inferior 1 (process 195969) exited normally]
(gdb) # Now you no longer have a live process, so you *again* can't
# call functions in it.
I use this (http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html) guide to learn how GDB works.
After compiling and uploading the code to my embedded linux arm platform I use a remote connection to connect with the gdbserver on my target:
Target:
root#zedboard-zynq7:/Software# gdbserver HOST:1234 broken
Process broken created; pid = 1103
Listening on port 1234
Remote debugging from host 192.168.178.32
Host (Ubuntu 14.04 running in a virtual machine):
Remote debugging using 192.168.178.33:1234
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB. Attempting to continue with the default arm settings.
Cannot access memory at address 0x0
0x43330d40 in ?? ()
(gdb)
I set the breakpoint to line 43 and continue the program until it stops at the breakpoint:
(gdb) b 43
Breakpoint 1 at 0x8b68: file broken.cpp, line 43.
(gdb) continue
Continuing.
Breakpoint 1, main () at broken.cpp:43
43 double seriesValue = ComputeSeriesValue(x, n);
(gdb)
But after a step call on my host I got this error:
Host:
warning: Remote failure reply: E01
Ignoring packet error, continuing...
Target:
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
What does it mean and how can I fix it?
Thanks for help.
Host (Ubuntu 14.04 running in a virtual machine):
Remote debugging using 192.168.178.33:1234
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB. Attempting to continue with the default arm settings.`
This says that your (host) GDB has not been built with support for the target you want to debug.
What does it mean and how can I fix it?
You need to either get a different build of (host) GDB, or build one yourself with correct --target setting.
Usually a correct host GDB is included with the cross-gcc that you use to build for your target. So a fix may be as simple as running /path/to/cross-gdb instead of gdb.
I am remote debugging a Stellaris Launchpad. I use OpenOCD to connect to the stellaris and then connect GDB to the server provided by openOCD. I use Open On-Chip Debugger 0.10.0-dev-00002-g79fdeb3 (2015-07-09-23:28). GDB is the one from arm-gcc-none-eabi, the 4_9-2015q1 release.
I invoke openOCD like this:
/usr/local/bin/openocd --file \
/usr/local/share/openocd/scripts/board/ek-lm4f120xl.cfg \
>> openocdLog.txt 2>&1 &
And then GDB like this:
arm-none-eabi-gdb proj//debug/exec -x gdb//gdb.script
gdb/gdb.script contains:
set remotetimeout 10000
target extended-remote :3333
monitor reset halt
load
monitor reset init
The problem is that whenever I hit control+c GDB disconnects. Normally this would halt the remote, but GDB just disconnects:
(gdb) cont
Continuing.
^CError detected on fd 6
Remote communication error. Target disconnected.: Interrupted system call.
(gdb)
OpenOCD has the following things to say, this one while GDB is launching:
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1258). Workaround: increase "set remotetimeout" in GDB
Which is weird, considering the gdb/gdb.script file forces remotetimeout to an insanly large number.
And when pressing control+c openOCD says:
Debug: 2602 5089 hla_interface.c:119 hl_interface_quit(): hl_interface_quit
So, how do I resolve this? How can I make GDB halt the remote instead of disconnecting when pressing control+c?
The problem was OpenOCD being too bleeding edge. I had issues with 0.6.1, but version 0.7.0 of OpenOCD works great.
Is it possible to run a process with gdb, modify some memory and then detach from the process afterwards?
I can't start the process from outside of gdb as I need to modify the memory, before the first instruction is executed.
When you detach from a process started with gdb, gdb will hang, but killing gdb from another process makes the debugged process still running.
I currently use the following script to launch the process:
echo '# custom gdb function that finds the entry_point an assigns it to $entry_point_address
entry_point
b *$entry_point_address
run
set *((char *)0x100004147) = 0xEB
set *((char *)0x100004148) = 0xE2
detach # gdb hangs here
quit # quit never gets executed
' | gdb -quiet "$file"
This happens in both of my gdb versions:
GNU gdb 6.3.50-20050815 (Apple version gdb-1824)
GNU gdb 6.3.50-20050815 (Apple version gdb-1822 + reverse.put.as patches v0.4)
I'm pretty sure that you can't detach from an inferior processes that was started directly under gdb, however, something like the following might work for you, this is based on a recent gdb, I don't know how much of this will work on version 6.3.
Create a small shell script, like this:
#! /bin/sh
echo $$
sleep 10
exec /path/to/your/program arg1 arg2 arg3
Now start this up, spot the pid from echo $$, and attach to the shell script like this gdb -p PID. Once attached you can:
(gdb) set follow-fork-mode child
(gdb) catch exec
(gdb) continue
Continuing.
[New process NEW-PID]
process NEW-PID is executing new program: /path/to/your/program
[Switching to process NEW-PID]
Catchpoint 1 (exec'd /path/to/your/program), 0x00007f40d8e9fc80 in _start ()
(gdb)
You can now modify the child process as required. Once you're finished just do:
(gdb) detach
And /path/to/your/program should resume (or start in this case) running.
I compiled gdbserver 7.6 for arm with:
cd /gdb-7.6-src/gdb/gdbserver
./configure --target=arm-linux --host=arm-linux
make CC=/path/to/cross-compiler-gcc
Then I compiled gdb 7.6 for arm with:
cd /gdb-7.6-src/
./configure --target=arm-linux --prefix=/opt/gdb-arm/install/
make && make install
I compiled my trivial application with:
/path/to/cross-compiler-gcc hello.c -g -o hello
I copied gdbserver and my cross-compiled application on my board.
From my pc (x86-pc-linux) I run:
gdb hello
(gdb) set target-async on
(gdb) tvariable $c
(gdb) actions
>teval $c=$c+1
>end
(gdb) break main
(gdb) target remote <ipaddr>:<port>
[Thread 1585] #1 stopped.
0x40000800 in ?? ()
Cannot access memory at address 0x0
(gdb) continue &
(gdb) tstart
Target does not support this command.
(gdb) tstatus
Target does not support this command.
The behaviour is 'normal' until the tstart command: I can debug the application as I want, but I am unable to start tracing the app.
The question is: does gdbserver support tracepoints for arm or only for x86/amd_64?
I was searching samething, what I've found in GDB online docs webdocs that there is no support for now to any Archs.
Check for more info:
https://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html
Quoting:
This functionality is implemented in the remote stub; however, none of the stubs distributed with GDB support tracepoints as of this writing