EDB don't resume program and step it

[GoogleCodeExporter]

When I attach edb to a process or start a programm under it, it is impossible 
to run the program.
It just step when I hit F9 or press the run button.
So I can't do anything.

I'm running edb on debian :
Linux debian 2.6.26-2-686 #1 SMP Tue Mar 9 17:35:51 UTC 2010 i686 GNU/Linux

edb version :
0.9.13

Original issue reported on code.google.com by evan.teran on 3 Oct 2012 at 3:21

[GoogleCodeExporter]

> When I attach edb to a process or start a programm under it, it is impossible
> to run the program.
> It just step when I hit F9 or press the run button.
> So I can't do anything.
> 
> I'm running edb on debian :
> Linux debian 2.6.26-2-686 #1 SMP Tue Mar 9 17:35:51 UTC 2010 i686 GNU/Linux
> 
> edb version :
> 0.9.13

OK
I've solved the problem, I don't know what you've done in your code but you 
don't call continue when F9 is hit
the solution is to add :
    if ((mode == MODE_RUNNING) || (mode == MODE_RUNNING_STEP))
    {
        edb::v1::debuggerBase->resume(DebuggerCoreInterface::DEBUG_CONTINUE);
    }
at line 1322 of DebuggerMain.cpp

Original comment by evan.teran on 3 Oct 2012 at 4:51

[GoogleCodeExporter]

Well I'm not sure why it wouldn't resume for you. I'll have to look into that. 
It definitely works in my builds.

Unfortunately, your "fix" isn't truely a fix. The problem is resuming from a 
breakpoint.

If the debugger is stopped on a breakpoint, i need to do the following to 
resume:

#1 unset the BP (so we can execute the instruction!)
#2 step 1 instruction
#3 re-enable the BP we disabled in #1 so it can be hit again
#4 if we are on a BP now (which can also be the same as from #1) then stop, we 
are done because we hit a BP
#5 if we aren't on a BP now, then do a full resume.

This is why the function you patched has things like this:

    if(mode == MODE_RUNNING) {
        mode = MODE_RUNNING_STEP;
    }

    m_StepMode = mode;

Which is my current (i am working on a better way) system for saying "step, but 
i really intend to run".

Either way, I'll try to setup a VM with the current Debian and see if I can 
replicate the bug.

Some things to check though:

Is the program using multiple threads, if so sometimes you can get weird 
behavior since edb isn't fully thread away.

Is the program using signals? Currently edb's handling of signals is... 
insufficient. I plan to improve this a lot soon.

As anything toyed with eflags? doing this can easily get the debugger into a 
"cannot resume, only step" state.

Thanks.

Original comment by evan.teran on 3 Oct 2012 at 4:52

[GoogleCodeExporter]

Please try the new version I just released (0.9.14). It uses a completely 
re-written event system.

Original comment by evan.teran on 3 Oct 2012 at 4:52

[GoogleCodeExporter]

Since I haven't heard back from you and the new event system is entirely 
re-written, I'm am tentatively marking this bug as "resolved, cannot reproduce".

If the latest version 0.9.15 has this issue for you, then please re-open this 
bug.

Also note, that I've recently found a linux kernel bug where stepping in a 
signal handler can result in the trap flag of the processor to get "stuck". I 
don't know if this is where you encountered the issue, but if it is, then the 
next kernel update should hopefully fix this.

Original comment by evan.teran on 3 Oct 2012 at 4:52

• Changed state: Fixed