Are you still using the python pretty printers?
Can you try to remove the two source commands?
I've tried both ways. I've run gdb.exe, gdb-python27.exe with both use pretty printers and without.
Essentially, gdbmi issues:
[debug]Executing command: c:\Usr\mingw461\bin\gdb.exe -fullname -quiet --interpreter=mi -args C:\Usr\Proj\cbDebug\trunk\src\devel\codeblocks.exe
done
[debug]Executor stopped
[debug]Debugger_GDB_MI::CommitBreakpoints
[debug]ActionsMap::Run -> starting action: 060A67D8 id: 1
[debug]RunAction::OnStart -> -exec-run
[debug]cmd==>10000000000-exec-run
[debug]output==>=thread-group-added,id="i1"
starts loading dll's and craps out on loading after about the 40th dll. It never gets to issue any other commands.
Note that gdbmi works from the command line. But if gdbmi is launched from debugger_gdbmi, it exits the i1 thread during dll loading. That means that one CB is already loaded, and gdbmi is loading another. If it's not sharing dll's it's loading multiple copies into memory.
I wonder if its running out of memory, though this system has 4 gigs and the regular gdb works. I cannot find those weird return codes anywhere on the internet.
The reason I'm guessing memory problems is because debugger_gdbmi work ok for me with small programs, like a wxWidgets Hello World program.
Is there any way you could upload your working gdb 7.4 to say a Dropbox public folder and let me try that?