Say I'm debugging a function like this
def foo {
byebug
x = 1+1
}
Running this, we hit the breakpoint. If I now hit "n", it runs the next line and exits the function. How can I instead remain in the function and inspect x?
Try finish 0.
The finish command should step out the number of frames you specify as an argument. If you specify 0, it has special behavior and just finishes the current frame without stepping out of it.
Related
I'm currently debugging the linux kernel and it's properly set up with kgdb.
I set a breakpoint to a function I am trying to debug, and the break occurs once I run my program which needs this kernel function to do something, this is wanted. But whenever I try to step through the code with "n" or "si", I always immediately land in arch/x86/include/asm/apic.h, which then runs some interrupt handling code and timers. I'm aware of the kernel being heavily parallelized so it has to move into some other code while being executed, but is it possible to step through the function more comfortably?
What I want to achieve:
before:
-> line A
line B
after:
line A
-> line B
What I have right now:
before:
-> line A
line B
after:
line A
... jumps into way different code here
I think it's hard. Let's think if the interrupts are all aborted, then how can you put your order by keybord or mouse?
When using Pycharm's debugger, the breakpoints hang if the code being inspected is inside of a function.
If I have a file with the code:
print("Hello")
print("World") # Breakpoint here
And I start a debugging REPL, it prints "Hello", then automatically switches to the "Deubgger" tab and shows the variables in scope. This is what I expect to happen.
If I put it in a function though:
def hello():
print("Hello")
print("World") # Breakpoint here
And then start a debugger REPL and call hello, it prints "Hello" then nothing happens. It just sits there. If I switch to the "Debugger" tab in the console, it's empty except for a "Connected" with an icon in the "Variables" box.
If I leave it long enough, it just seemingly silenty fails and exits the function?:
>>> hello()
Hello
# A few minutes later
>>> # "World" is never printed and it returns.
This is the first time I've used Pycharm's debugger, but I've used IntelliJ's, and it worked as I expected. This issue has survived restarting both the computer.
Does anyone know why the debugger is hanging is this case?
Normally if you set a gdb breakpoint and the the program hits that point, gdb stops execution entirely and lets the user examine and poke around before continuing.
I want the option to be notified of the breakpoint traversal, but not halt execution.
I know I could simply go to the code and add a print statement, but this is annoying especially debugging libraries outside my code which I am not building myself.
Again, I'm already using GDB and want to use 'breakpoints' but just get some sort of notification of when and how many times a line is traversed without halting the whole program's execution. Is this possible?
I want the option to be notified of the breakpoint traversal, but not halt execution.
(gdb) break foo.c:123
(gdb) commands $bpnum
continue
end
This attaches a command to the breakpoint. GDB will print that a breakpoint is hit, then run the attached command, which will continue execution.
You could also print some variables before continuing, or even continue only if some condition is true, and stop otherwise. E.g. "continue if x > 100, but stop if it's not".
I've implemented this code in my .gdbinit file to make stop-requiring gdb commands work(such as x, set etc)
define hook-x
if $pince_debugging_mode == 0
interrupt
end
end
define hook-stop
if $pince_debugging_mode == 0
c &
end
end
The purpose of $pince_debugging_mode variable is to inform gdb if the program is interrupting the target for debugging purposes or not.
I have a concern about signal concurrency with this design: Lets say we put a breakpoint on an address and while waiting it to get triggered we wanted to check some addresses with the x command. After x command gets executed, hook-stop will get executed because we have stopped the thread with the x command. And lets say breakpoint has been reached while hook-post is executing but hook-stop isn't aware of that and the $pince_debugging_mode still equals to 0 so it'll execute the c & command and the target will continue. So the stop at breakpoint won't mean anything because of this concurrency problem.
This problem never occurred yet but I'm afraid of the odds of occurring, even if it's very low, I don't want to take the risk. What can I do to avoid this possible problem?
Note: defining a hookpost-x is problematic because whenever x command throws an exception hookpost won't get executed, so it'll be impossible to continue after a exception-throwing x command
The first Curses.getstr call clears another window. On later calls it doesn't happen.
require "curses"
Curses.init_screen
window = Curses::Window.new(10, 10, 5, 0)
window.scrollok true
Thread.new do
loop do
window.addstr rand(1000000).to_s
window.refresh
sleep 0.1
end
end
Curses.setpos 20, 0
sleep 1
# now several lines of numbers suddenly disappear
loop{ Curses.getstr }
How can I fight this behaviour?
What you're seeing is an implicit refresh() of the stdscr window -- because getstr() is really wgetstr(stdscr). Your options include:
Manually refreshing stdscr before drawing anything
Using your new window for input, rather than stdscr, and/or
Using stdscr for output.
At least, that's the answer I'd give for curses' native C -- I'm not sure how it translates to Ruby.