I've run into a bit of an issue. I'm debugging a BOCHS OS emulator in GDB, and it sends Signal 0 fairly often (every time there is a page fault). I was wondering if there was a way to explicitly tell gdb to not break/stop execution on signals?
I've tried "handle all nostop" and specifically "handle 0 nostop", but it doesn't work.
Let me know if there's any additional information I can provide. I'd consider myself only an intermediate gdb user, so any help is great!
I've read this SO question and this man page but neither worked.
I believe you want to set
handle 0 noprint
From the man page
GDB should not mention the occurrence of the signal at all. This implies the nostop keyword as well.
If you run info signals in gdb, it gives you a list of signals by name, which works fine with handle.
For example:
(gdb) handle SIG34 noprint
Signal Stop Print Pass to program Description
SIG34 No No Yes Real-time event 34
Related
got some big real time project to deal with (multiple processes (IPCs), multi Everything in short).
My working on process is started as service on Linux. I have the root access.
Here is the problem:
I'm trying to attach to a running proc, tried starting it through/with gdb but the result is the same: it stops the executable once I "touched" it with gdb or sometimes it throws:
Program received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x7f9fe869f700 (LWP 2638)]
of course from there nothing can be done.
Tried:
handle all nostop
attach to launched as service (daemon) or launched as regular proc
started from gdb
thought maybe forking/multi-threaded problem - implemented in the very beginning sleep for 10 seconds - attached to it with "continue"
Guys, all I want it is to debug, hit the breakpoints, etc.
Please help! Share ideas.
Editing actual commands:
1) gdb attach myProcId. Then after reading symbols, I hit "c" which results:
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7f9fe869f700 (LWP 2638)]
0x00007f9fec09bf73 in select () from /lib64/libc.so.6
2) If I make the first line 10 seconds sleep in the code, attaching to the process, hit "c", result: it runs, shows info threads, backtrace of main, but never hits the breakpoint (for sure the code runs there - I get logs and different behaviour if I change code there), meaning the process is stuck.
3) All other combinations like gdb path/to/my/proc args list, then start. Where arg list played with different related options gdb gives us.
Maybe worth to mention: process network packets related, timers driven also.
But for me the important thing is a current snapshot on break, i don't care what will happen to the system after timers expired.
Since you mentioned that you are debugging a multiprocessing program, I think the underlying program you have is to set the breakpoint in the correct subprocess.
Try break fork and set follow-fork-mode child/parent. What you want to achieve is have gdb attached to the process that is running the code you want to debug.
Refer to this link.
Another thought is to generate a crash, since you can compile the programe. For example add a int i = *(int*)NULL and that will generate a core dump. You can then debug the core dump with gdb <program> <core dump>. You can refer to this page for how to configure core dump.
I've made sure to build my D program with the -g flag (add symbolic debug info) and it looks like I can set simple LOC breakpoints in both GDB and LLDB like this: b SomeModule.d:42 - the debugger replies with a memory address for the new breakpoint.
However when I run the program from the debugger, it gets stopped somewhere completely different than SomeModule.d:42. What am I missing?
D is a safe by default, garbage-collected by default, language.
So in addition to your own breakpoints, programs will often be interrupted by the Garbage Collector Signals (SIGUSR1, SIGUSR2).
In GDB, this can be prevented by:
(gdb) handle SIGUSR1 nostop noprint
Signal Stop Print Pass to program Description
SIGUSR1 No No Yes User defined signal 1
(gdb) handle SIGUSR2 nostop noprint
Signal Stop Print Pass to program Description
SIGUSR2 No No Yes User defined signal 2
Even better, automate by putting the above 2 commands in a file and start GDB with -x gdb_command_file.
The corresponding LLDB-ese sounds different:
(lldb) process handle --stop false --notify false SIGUSR1 SIGUSR2
I'm not sure it's possible to automate it similarly with LLDB alone.
Came across this doc: https://idea.popcount.org/2012-12-11-linux-process-states/ (a bit old). It says ptrace is handling debugee's signals by receiving SIGCHLD. Is GDB relying on this?
Related, does GDB get notification when signal handler is set to "noprint nostop pass"?
Further, the doc above says, in the case of ptrace, system blocks debuggee when some signal happens, until debugger finishes handling and continues debugee by waitpid(). Is this still the case nowadays?
Thanks in advance!
The answer is "yes" to every single question you posed, except:
and continues debugee by waitpid()
The waitpid doesn't continue debuggee, merely waits for it. The "continue" is done with (surprise!) ptrace(PTRACE_CONT, ...).
I'm trying to debug proftpd in order to understand better this exploit http://www.phrack.org/issues.html?issue=67&id=7. The vulnerable section is in mod_sql.c, I have tried to breakpoint the sql_prepare_where function (that is where the heap overflow is done) and then call the USER ... and PASS ... command but it is never triggered.
To find out why I have breakpoints all the hundreds line of mod_sql.c and then launch the program (with full debugging option), some breakpoints are triggered (sql_setuserinfo, set_sqlauthenticate, get_auth_entry...) but only at the very beginning of the launching process, then when the program goes in it main loop nothing else breakpoint related happens (while the log of proftpd mentions that the USER and PASS commands are dispatched to mod_sql.c)..
Would anyone know what I'm missing?
[ It's possible I am missing something essential of GDB, I am learning on the roll :) ]
Server programs often use a "separate program for each connection" method, where after successful accept, the parent forks a child to handle current connection, and goes back to accepting more connections.
I don't know for sure, but if proftpd used that model, it would explain exactly the symptoms you've described.
You can ask GDB to debug the child instead of the parent, by using (gdb) set follow-fork-mode child.
I use ddd as a front-end for both gdb and dbx for C++ programs.
Quite often, without any apparent cause, I will try to next and it will hang with the message "Waiting for gdb to get ready" or "Waiting for dbx to get ready".
Does anybody know what it is that they're doing that takes forever and produces no apparent results? And can I stop it from happening?
Bear in mind that enough stuff has already been loaded that I have quite happily been stepping/nexting a minute earlier in the same process (and in the same function), so whatever they're doing doesn't seem to have been necessary for that. Also the fact that both ddd and dbx have the same pattern of behaviour (in many different executables and on different platforms) makes me think it's something in the data rather than a bug in either debugger.
GDB (and the same applies for DBX) communicate with DDD with the MI protocol, which is a standardize and unambiguous equivalent of the command-line interface.
Remark: the default in my system (Fedora 15) seems to be that they communicate directly using the CLI, but I only noticed the problem you describe with --interpret=mi.
For instance, here are the respective output to get the thread list:
(gdb) info threads
Id Target Id Frame
2 Thread 0x7ffff7fd2700 (LWP 9191) "philosophers" 0x00000037dcc0b4c5 in pthread_cond_wait##GLIBC_2.3.2 () from /lib64/libpthread.so.0
1 Thread 0x7ffff7fd3720 (LWP 9182) "philosophers" 0x00000037dc8df461 in clone () from /lib64/libc.so.6
(gdb) -thread-info
^done,threads=[
{id="2",target-id="Thread 0x7ffff7fd2700 (LWP 9525)",name="philosophers",
frame={level="0",addr="0x0000000000400b31",
func="chopsticks_put",
args=[{name="i",value="0"}],
file="chopsticks.c",fullname="philosphers/chopsticks.c",line="70"},
state="stopped",core="2"},
{id="1",target-id="Thread 0x7ffff7fd3720 (LWP 9522)",name="philosophers",
frame={...},
state="stopped",core="1"
}],current-thread-id="3"
So what you will see in DDD will be quite similar to what is available in the CLI, only the 'presentation layer' is different.
From my experience, most of GDB commands are very fast, at least when they don't depend on the debuggee execution (like a next over a sleep(5)). So there are two possibilities for your problem:
a bug in the communication: for instance a ^done tag is missed by DDD or forgotten by GDB, so DDD waits in vain for the termination of its request
DDD asks GDB for a lot of data, like the definition of structures, function locations or memory contents, etc. (for instance because of the elements you want to watch), so it will take some time for the information to be computed by GDB and transferred to DDD.
At the bottom of DDD you have the GDB console. Try typing some GDB commands in there. If GDB responds correctly (my case) it means that DDD is not synchronized with GDB anymore. (DDD is getting old, 2009/02/11, and MI is extensively used by Eclise, so I think we know who has to be blamed...!)