In a traditional imperative debugger such as gdb it is possible to break into program executing with SIGINT, inspect the program state, and eventually resume execution.
While GHCi allows one to break into program execution at an arbitrary point with -fbreak-on-exception, attempting to resume execution with :continue will only lead to the interpreter continuing on with the exception handler and terminating the program,
> let main = findCureForCancer
> :set -fbreak-on-exception
> :trace main
[twiddle thumbs]
[why is this taking so long?]
[maybe something is wrong, I better see what it's doing]
^CStopped at <exception thrown>
_exception :: e = GHC.Exception.SomeException
GHC.IO.Exception.UserInterrupt
> :hist
...
[ahh, looks like this will just take a bit longer]
> :continue
[program should keep running]
Is it possible to break into execution and still resume execution after poking about a bit with the GHCi debugger?
I’m no GHC expert, but I am extremely confident that neither stable GHC nor the current GHC HEAD supports this. The manual mentions nothing about it, and I’ve sourcedived the current HEAD to make sure there’s nothing undocumented, commented out, or surrounded in an #if FALSE. (If you’re interested, the currently-impemented GHCi commands are defined at /ghc/InteractiveUI.hs:136.) Nothing has been posted on the mailing list about this, at least since January 2013, and nobody has filed or closed a bug about it (see the relevant bug tracker search).
This sounds like it would be a useful feature to have – would you file a feature request?
Related
Most debuggers with GUI have a useful function run to cursor. Is there any similar way of doing this in gdb?
I'm talking about assembly mode debugging (without source code).
For example, it currently break at: 0x400000, I'd like to run to 0x400100, there're lots of instructions between them. To do this, I have to:
set breakpoint at 0x400100 with b *0x400100,
continue with c
delete breakpoint with d ...
It is lots of typing, and I need to do this frequently. Any simpler way of doing this?
You are looking for either "until" or "advance" command.
Details in GDB manual chapter Continuing and Stepping.
If stopping on frame exit is problematic, you can still use tbreak, which sets temporary breakpoint, which is automatically deleted once it is hit.
This is my first question in Stack Overflow, since up until now, I always managed to find my answers.
So.. I'm writing a debbuger (for Windows, in python, using WinAppDbg library) that should trace the program execution, and encountered some problems.
I'm setting the trap flag, so I could stop every single step.
First problem - sometimes the execution flow goes through a Windows api, which goes to the kernel. When it returns, obviously the trap flag is off, and the execution of the thread may continue millions of instructions without my debbuger tracing every step of it.
Chance of solution - before a Windows api is called, I set the next addresses permissions as guard page, thus when the call returns, I get a guard page exception, setting the trap flag again, and continue tracing. But this cause a different problem (I call it "second problem")
Second problem - since I'm setting the trap flag of my main thread, all I see is a loop of that thread (I guess it's the Windows gui loop), and the program execution isn't advancing (for example, there should be new threads created, but I don't see them).
So what am I looking for?
A debugger's source code that can handle the problems I've described.
Or better yet, a solution to my problems. What am I doing wrong?
Thank you all!
I'm trying to dump a backtrace of a passenger process in gdb. I know I should just execute
attach <PID>
call rb_backtrace()
after starting gdb, but I can't figure out where the output is going, I've looked at rails production logs (set to info), nginx logs in /var/logs/nginx but I can't find the output. Any ideas?
I don't know the answer on the ruby end -- I'd guess it is going to the ruby process' stdout or stderr -- but gdb recently got a new feature that is designed to help with this scenario.
The new feature is called "frame filters" and it lets you change how stack traces are presented by writing simple Python scripts that examine the state of the inferior process. For example, you could write such a script that understands the Ruby interpreter, and then have gdb's "bt" automatically interleave interpreted (Ruby) frames with C frames.
For more information, start here and read the next few nodes: http://sourceware.org/gdb/current/onlinedocs/gdb/Frame-Filter-API.html#Frame-Filter-API
I'd like to see this feature be adopted by the various interpreter projects. There's been pretty good adoption of pretty printing, and I think this is a logical next step.
UPDATE: Problem located in my related question - Nokogiri performance problem
I am having a serious problem with my program. After program reaches it's last statement, Aptana studio shows the program is still running even after the last line was evaluated. Ruby process (after the last line of the script) is still running with 100% CPU usage, it ends after several seconds (15-30 maybe). I am trying to at atleast see where the problem is but after a long time I am still at the beginning. So the question is, what could cause this problem and how can I at least see where the problem is, what are my options? Some additional information:
Aptana debbug mode: After the last line, this will show in the Debug window:
<terminated, exit value: 0>path/to/ruby
But Ruby process is still running and using 100% CPU
I was trying to use gdb to profile Ruby process itself, but ended up with nothing using method described here: Profilig using gdb. I am using debian squeeze 64-bit and i tried both versions of script (8,12 > 16,24). When I tried to get some stack info I just get this:
Program received signal SIGSEGV, Segmentation fault.
0x00007f20539a80b8 in ?? () from /lib/libc.so.6
/home/giron/programovani/gdb_init.sh:1: Error in sourced command file:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(backtrace) will be abandoned.
When the function is done executing, GDB will silently stop.
After I quit gdb, following output shows up in Aptana console (But this is maybe absolutely useless, probably gdb did this, I don't know):
/home/giron/Aptana Studio 3 Workspace/RedisXmlConcept/bin/main.rb: [BUG] Segmentation fault
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
-- control frame ----------
c:0001 p:0000 s:0002 b:0002 l:000f68 d:000f68 TOP
---------------------------
-- C level backtrace information -------------------------------------------
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(rb_vm_bugreport+0x5f)[0x7f205488216f]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(+0x63274) [0x7f205476a274]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(rb_bug+0xb3) [0x7f205476a413]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(+0x10c215) [0x7f2054813215]
/lib/libpthread.so.0(+0xeff0) [0x7f20544f9ff0]
/lib/libc.so.6(+0xe40b8) [0x7f20539a80b8]
/lib/libgcc_s.so.1(_Unwind_Backtrace+0x49) [0x7f2050d5b599]
/lib/libc.so.6(backtrace+0x4e) [0x7f20539a81ae]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/bin/ruby(_start+0) [0x400890]
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
Just to be sure that I have described problem well, last line of code (before this, Nokogiri parsing and work with Redis database is done):
puts "End"
End is printed out and after this Ruby process will consume 100% CPU for several seconds
This question is related to my previous one here: Nokogiri performance problem where are some more code snippets but since I am focusing on the different approach here (profiling Ruby), I have created new question.
Thank you in advance for any tips, I am pretty much clueless right now.
I was trying to use gdb to profile Ruby process itself
Don't do that. Calling backtrace may not be safe in the context you are executing in, and (apparently) causes your program to SIGSEGV.
Instead, just attach gdb to the Ruby process, and execute thread apply all where command. Update your question with the output, and you may get a better answer.
I would like the command gdb on program X to instead switch to an existing debugging session of X if it already exists instead of signalling an error "This program is already being debugged" in gud-common-init.
I believe this is important as it makes the behaviour of gdb harmonize with the standard behaviour of most other Emacs interactions such as, find-file, switch-to-buffer etc, thus creating less confusion to the user.
So far I have modified the line containing
(error "This program is already being debugged"))
to instead do
(message "This program is already being debugged")
to at least prevent the error from arising. However, the function gdb does some extra initializations that should not be needed that causes some unnecessary delays. Is this a todo item or have I missed some gud/gdb-function that does this already?
Many thanks in advance,
Per Nordlöw
You can always rename-buffer. This is how I can run multiple gdb sessions on the same executable. It is not automatic but it is an effective work around.
For example if my executable is called pump, then upon running gdb, a buffer named *gud-pump* will be generated which represents the gdb session. From this buffer do meta-x rename-buffer *gud-pump1*
Then invoke gdb again and you will have two GUD sessions, one *gud-pump* and *gud-pump1*. The sessions are separate and should not interfere (although they can interact) with each other.