User forums > Using Code::Blocks
Debugger plugin issue when I click the "Setp into instruction"
ollydbg:
Hi, when debugging, I click the "Step into instruction", then the debugger plugin just has no further response. The whole C::B is still active without hanging.
Here is the debug log:
--- Code: ---[debug]> next
[debug]E:\code\gdb-debug1\main.cpp:9:119:beg:0x401586
[debug]>>>>>>cb_gdb:
At E:\code\gdb-debug1\main.cpp:9
[debug]> if 1
disassemble 0x401586
info frame
end
[debug] > > >
--- End code ---
This happens in the latest nightly 64bit C::B and a self build 32 bit C::B.
The GDB I'm using is: either 64bit GDB 8.1 or GDB 20190111(git head) version build myself.
Any ideas.
EDIT:
This issue also happens when you have "Disassmbler" window opened.
ollydbg:
Here is the log I run GDB under command line:
--- Code: ---D:\code\gdb-test\bin\Debug>gdb gdb-test.exe
D:\code\gdbmybuild\bin\gdb.exe: warning: Couldn't determine a path for the index cache directory.
GNU gdb (GDB) 8.2.50.20190111-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gdb-test.exe...
(gdb) b main.cpp:10
Breakpoint 1 at 0x401649: file main.cpp, line 10.
(gdb) r
Starting program: D:\code\gdb-test\bin\Debug\gdb-test.exe
[New Thread 6572.0x16c4]
Do you need "set solib-search-path" or "set sysroot"?
Hello world!
Breakpoint 1, main () at main.cpp:10
10 int b = 0;
(gdb) stepi
11 a++;
(gdb) nexti
12 a= a+6;
(gdb) disas
Dump of assembler code for function main():
0x00401600 <+0>: lea 0x4(%esp),%ecx
0x00401604 <+4>: and $0xfffffff0,%esp
0x00401607 <+7>: pushl -0x4(%ecx)
0x0040160a <+10>: push %ebp
0x0040160b <+11>: mov %esp,%ebp
0x0040160d <+13>: push %ecx
0x0040160e <+14>: sub $0x24,%esp
0x00401611 <+17>: call 0x401870 <__main>
0x00401616 <+22>: movl $0x404045,0x4(%esp)
0x0040161e <+30>: movl $0x6ff05a00,(%esp)
0x00401625 <+37>: call 0x4016d4 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x0040162a <+42>: movl $0x4016dc,(%esp)
0x00401631 <+49>: mov %eax,%ecx
0x00401633 <+51>: call 0x4016f4 <_ZNSolsEPFRSoS_E>
0x00401638 <+56>: sub $0x4,%esp
0x0040163b <+59>: movl $0x0,-0xc(%ebp)
0x00401642 <+66>: movl $0x3,-0xc(%ebp)
0x00401649 <+73>: movl $0x0,-0x10(%ebp)
0x00401650 <+80>: addl $0x1,-0xc(%ebp)
=> 0x00401654 <+84>: addl $0x6,-0xc(%ebp)
0x00401658 <+88>: mov -0xc(%ebp),%eax
0x0040165b <+91>: add $0x1,%eax
0x0040165e <+94>: mov %eax,-0x10(%ebp)
0x00401661 <+97>: addl $0x1,-0x10(%ebp)
0x00401665 <+101>: addl $0x4,-0x10(%ebp)
0x00401669 <+105>: mov $0x0,%eax
0x0040166e <+110>: mov -0x4(%ebp),%ecx
0x00401671 <+113>: leave
0x00401672 <+114>: lea -0x4(%ecx),%esp
0x00401675 <+117>: ret
End of assembler dump.
(gdb) if 1
>disassemble 0x00401650
>info frame
>end
Dump of assembler code for function main():
0x00401600 <+0>: lea 0x4(%esp),%ecx
0x00401604 <+4>: and $0xfffffff0,%esp
0x00401607 <+7>: pushl -0x4(%ecx)
0x0040160a <+10>: push %ebp
0x0040160b <+11>: mov %esp,%ebp
0x0040160d <+13>: push %ecx
0x0040160e <+14>: sub $0x24,%esp
0x00401611 <+17>: call 0x401870 <__main>
0x00401616 <+22>: movl $0x404045,0x4(%esp)
0x0040161e <+30>: movl $0x6ff05a00,(%esp)
0x00401625 <+37>: call 0x4016d4 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x0040162a <+42>: movl $0x4016dc,(%esp)
0x00401631 <+49>: mov %eax,%ecx
0x00401633 <+51>: call 0x4016f4 <_ZNSolsEPFRSoS_E>
0x00401638 <+56>: sub $0x4,%esp
0x0040163b <+59>: movl $0x0,-0xc(%ebp)
0x00401642 <+66>: movl $0x3,-0xc(%ebp)
0x00401649 <+73>: movl $0x0,-0x10(%ebp)
0x00401650 <+80>: addl $0x1,-0xc(%ebp)
=> 0x00401654 <+84>: addl $0x6,-0xc(%ebp)
0x00401658 <+88>: mov -0xc(%ebp),%eax
0x0040165b <+91>: add $0x1,%eax
0x0040165e <+94>: mov %eax,-0x10(%ebp)
0x00401661 <+97>: addl $0x1,-0x10(%ebp)
0x00401665 <+101>: addl $0x4,-0x10(%ebp)
0x00401669 <+105>: mov $0x0,%eax
0x0040166e <+110>: mov -0x4(%ebp),%ecx
0x00401671 <+113>: leave
0x00401672 <+114>: lea -0x4(%ecx),%esp
0x00401675 <+117>: ret
End of assembler dump.
Stack level 0, frame at 0x28fed0:
eip = 0x401654 in main (main.cpp:12); saved eip = 0x4013eb
source language c++.
Arglist at 0x28feb8, args:
Locals at 0x28feb8, Previous frame's sp is 0x28fed0
Saved registers:
ebp at 0x28feb8, eip at 0x28fecc
(gdb)
--- End code ---
And Here is the test code:
--- Code: ---#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
int a = 0;
a = 3;
int b = 0;
a++;
a= a+6;
b = a+1;
b++;
b = b+4;
return 0;
}
--- End code ---
So, I guess it is a C::B related issue.
ollydbg:
OK, I debugged for a while, in this function call: void GDB_driver::ParseOutput(const wxString& output)
The argument L" > > >" is the output from GDB. so maybe C::B thought there are still some GDB command user has to enter.
--- Code: ---[debug]#0 GDB_driver::ParseOutput (this=0xbdb7450, output=L" > > >") at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\debuggergdb\gdb_driver.cpp:693
[debug]#1 0x67d4ff17 in DebuggerGDB::ParseOutput (this=0x72da698, output=L" > > >") at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\debuggergdb\debuggergdb.cpp:1740
[debug]#2 0x67d51866 in DebuggerGDB::OnGDBOutput (this=0x72da698, event=...) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\debuggergdb\debuggergdb.cpp:1879
[debug]#3 0x66482d92 in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#4 0x66483267 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#5 0x665d9bde in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#6 0x665d9d2a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#7 0x665da431 in wxEvtHandler::TryHereOnly(wxEvent&) () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#8 0x665da49a in wxEvtHandler::ProcessEventLocally(wxEvent&) () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#9 0x665da4f3 in wxEvtHandler::ProcessEvent(wxEvent&) () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#10 0x665dbb53 in wxEvtHandler::ProcessPendingEvents() () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#11 0x66484b40 in wxAppConsoleBase::ProcessPendingEvents() () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#12 0x664b6328 in wxEventLoopManual::ProcessEvents() () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#13 0x664b63fd in wxEventLoopManual::DoRun() () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#14 0x664b6103 in wxEventLoopBase::Run() () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#15 0x664881b4 in wxAppConsoleBase::MainLoop() () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#16 0x00404dae in CodeBlocksApp::OnRun (this=0x3bde520) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\src\app.cpp:870
[debug]#17 0x664fe3b1 in wxEntryReal(int&, wchar_t**) () from D:\code\wxWidgets-3.1.2\lib\gcc_dll\wxmsw312u_gcc_cb.dll
[debug]#18 0x004021db in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0, nCmdShow=10) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\src\app.cpp:338
[debug]#19 0x0050644d in main ()
--- End code ---
The bad thing is: after this "GDB_driver::ParseOutput" function call, I never see another function call, which means the GDB prompt string never returned? :( If that's true, the problem is hard to solve.
EDIT:
If I paste the below command to the GDB command line, I see the GDB prompt correctly returned.
--- Code: ---if 1
disassemble 0x00401650
info frame
end
--- End code ---
See the log:
--- Code: ---Breakpoint 1, main () at main.cpp:10
10 int b = 0;
(gdb) if 1
>disassemble 0x00401650
>info frame
>end
Dump of assembler code for function main():
0x00401600 <+0>: lea 0x4(%esp),%ecx
0x00401604 <+4>: and $0xfffffff0,%esp
0x00401607 <+7>: pushl -0x4(%ecx)
0x0040160a <+10>: push %ebp
0x0040160b <+11>: mov %esp,%ebp
0x0040160d <+13>: push %ecx
0x0040160e <+14>: sub $0x24,%esp
0x00401611 <+17>: call 0x401870 <__main>
0x00401616 <+22>: movl $0x404045,0x4(%esp)
0x0040161e <+30>: movl $0x6ff05a00,(%esp)
0x00401625 <+37>: call 0x4016d4 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x0040162a <+42>: movl $0x4016dc,(%esp)
0x00401631 <+49>: mov %eax,%ecx
0x00401633 <+51>: call 0x4016f4 <_ZNSolsEPFRSoS_E>
0x00401638 <+56>: sub $0x4,%esp
0x0040163b <+59>: movl $0x0,-0xc(%ebp)
0x00401642 <+66>: movl $0x3,-0xc(%ebp)
=> 0x00401649 <+73>: movl $0x0,-0x10(%ebp)
0x00401650 <+80>: addl $0x1,-0xc(%ebp)
0x00401654 <+84>: addl $0x6,-0xc(%ebp)
0x00401658 <+88>: mov -0xc(%ebp),%eax
0x0040165b <+91>: add $0x1,%eax
0x0040165e <+94>: mov %eax,-0x10(%ebp)
0x00401661 <+97>: addl $0x1,-0x10(%ebp)
0x00401665 <+101>: addl $0x4,-0x10(%ebp)
0x00401669 <+105>: mov $0x0,%eax
0x0040166e <+110>: mov -0x4(%ebp),%ecx
0x00401671 <+113>: leave
0x00401672 <+114>: lea -0x4(%ecx),%esp
0x00401675 <+117>: ret
End of assembler dump.
Stack level 0, frame at 0x28fed0:
eip = 0x401649 in main (main.cpp:10); saved eip = 0x4013eb
source language c++.
Arglist at 0x28feb8, args:
Locals at 0x28feb8, Previous frame's sp is 0x28fed0
Saved registers:
ebp at 0x28feb8, eip at 0x28fecc
(gdb)
--- End code ---
oBFusCATed:
The problem is not step into instruction, but the disassembly command. For some reason I don't know it is broken on windows. If you can debug it and understand why it happens it would be good.
ollydbg:
--- Quote from: oBFusCATed on January 12, 2019, 11:37:41 am ---The problem is not step into instruction, but the disassembly command. For some reason I don't know it is broken on windows. If you can debug it and understand why it happens it would be good.
--- End quote ---
I found that the cause happens that we send several command to GDB separated by \n does not works.
If I change the code:
--- Code: --- src/plugins/debuggergdb/gdb_commands.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/plugins/debuggergdb/gdb_commands.h b/src/plugins/debuggergdb/gdb_commands.h
index 65bc040e..18901b96 100644
--- a/src/plugins/debuggergdb/gdb_commands.h
+++ b/src/plugins/debuggergdb/gdb_commands.h
@@ -1496,21 +1496,21 @@ class GdbCmd_DisassemblyInit : public DebuggerCmd
m_disassemblyFlavor(disassemblyFlavor),
m_hexAddrStr(hexAddrStr)
{
- m_Cmd << _T("if 1\n") ;
+ //m_Cmd << _T("if 1\n") ;
if(m_hexAddrStr.empty())
{
const Cursor &cursor = driver->GetCursor() ;
if(cursor.address.empty())
- m_Cmd << _T("disassemble $pc,$pc+50\n") ;
+ m_Cmd << _T("disassemble $pc,$pc+50\n") ;
else
{
- m_Cmd << _T("disassemble ") << cursor.address << _T("\n") ;
+ m_Cmd << _T("disassemble ") << cursor.address;// << _T("\n") ;
}
}
else
- m_Cmd << _T("disassemble ") << m_hexAddrStr << _T("\n") ;
+ m_Cmd << _T("disassemble ") << m_hexAddrStr;// << _T("\n") ;
- m_Cmd << _T("info frame\n") << _T("end");
+ //m_Cmd << _T("info frame\n") << _T("end");
};
void ParseOutput(const wxString& p_output)
--- End code ---
Then, I see only one gdb command(the disassemble command) was send to GDB, and I see GDB can correctly print the disassemble result.
While, if we send the whole command like:
--- Code: ---if 1\ndisassemble 0x00401650\ninfo frame\nend\n
--- End code ---
Then GDB doesn't print the disassembled result, and only the three "> > >" was returned, and the GDB prompt is lost. I believe this time, GDB has some internal issue to handle the multiple commands.
So, I think it is not easy to fix such issue in C::B side. Unless we send command several times.
Navigation
[0] Message Index
[#] Next page
Go to full version