User forums > Nightly builds

The 17 September 2011 build (7452) DEBUGGER BRANCH version is out.

<< < (7/9) > >>

ollydbg:
@obf, I found a tiny bug.

When I try to run a gdb command in the command edit control which is in the bottom of the debugger/debugger log panel. I found that some times, I will lose the focus, but some times I still get the focus in the edit control.

Here is a test program:

--- Code: ---int main()
{
    int a = 0;
    a++;
    a=3;
    ;
}

--- End code ---
The, I set a breakpoint in the line 3.

CASE one (good case) :
I just run the command "p a", then gdb will show its value, this way, I still get the focus, so I can still press the keyboard, and enter other command again.

CASE two (bad case):
Enter the command "p b". Note, b is not defined in the context, so gdb will complain:

--- Code: ---> p a
$6 = 1
> p b
No symbol "b" in current context.
--- End code ---
But after that, I loss my edit focus.

I just test under WinXP. Can someone reproduce this bug?

oBFusCATed:
ollydbg: Can reproduce on linux.

MortenMacFly:
C::B debugger's branch, latest revision, Windows 7 / 64 bit, TDM GCC 64 bit compiler suite.

When I compile a simple wxWidgets based "Hello World" app (wxWidgets 2.9.2, compiled for 64 bit) whenever I start the debugger, C::B stalls. The stop / pause button does not work, the debugger it becomes in-responsible until I kill the gdb process.

The reason seems the following:
In the debugger's debug log I see:

Command-line: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet -args C:/Code/CodeBlocks_Projects/HelloWorld/HelloWorld_64.exe
Working dir : C:\Code\CodeBlocks_Projects\HelloWorld
> set prompt >>>>>>cb_gdb:
"c:\code\codeblocks_projects\helloworld\HelloWorld_64.exe": not in executable format: File format not recognized
(gdb) >>>>>>cb_gdb:

...later on:

> run
No executable specified, use `target exec'.


It seems GDB is waiting for an input here. :-(

I know (meanwhile) that TDM's 64 bit compiler suite ships with a debugger not valid for 64 bit, however, the freeze shouldn't happen. Did somebody else experience the same?

Jenna:
I get a similar issue on linux, if the executable does not exist and "autobuold to ensure project is up to date" (or how it is called exactly) is unchecked.
gdb hangs and can not be stopped with pause- or stop-button:

--- Code: ---> run
No executable file specified.
Use the "file" or "exec-file" command.
>>>>>>cb_gdb:
Code::Blocks is trying to interrupt process with pid: 23917; child pid: 0 gdb pid: 23917
Quit
>>>>>>cb_gdb:
Code::Blocks is trying to interrupt process with pid: 23917; child pid: 0 gdb pid: 23917
Quit
>>>>>>cb_gdb:
--- End code ---
First try was pause, second was stop.

In trunk stopping gdb works.

23917 is the pid of gdb and killing it from commandline with default signal (TERM [15]) works.

oBFusCATed:
As I've said to Morten on PM, I'll look in to the problem (not sure when, because I have some other things to do at the moment).
Stopping doesn't work, because C::B is sending SIGINT to the child of gdb, not to gdb directly.
I'll look in to this, too, it is on the TODO, thanks for the test case.

Navigation

[0] Message Index

[#] Next page

[*] Previous page