User forums > Using Code::Blocks
Very slow stepping while debugging on Linux
ollydbg:
Another question: is it slow when you debug a program under GDB directly, I mean start GDB from bash command line without C::B.
tomazzi:
Hi,
I'm experiencing the same annoying problem for some time (Debian12, CB svn13368) and today I decided to do some research.
To track the issue I've added stderr logging to DebuggerDriver::RunQueue() as follows:
--- Code: ---void DebuggerDriver::RunQueue()
{
wxLogStderr ErrLog;
wxString tmps;
if (m_QueueBusy || !m_DCmds.GetCount() || !IsProgramStopped())
return;
DebuggerCmd *command = CurrentCommand();
tmps.Printf("DebuggerDriver::RunQueue(): m_DCmds.Count %ld, m_Cmd: '",
m_DCmds.GetCount());
tmps << command->m_Cmd << "'\n";
ErrLog.LogText(tmps);
// Log(_T("Running command: ") + CurrentCommand()->m_Cmd);
// don't send a command if empty; most debuggers repeat the last command this way...
if (!command->m_Cmd.IsEmpty())
{
m_QueueBusy = true;
m_pDBG->DoSendCommand(command->m_Cmd);
if (command->IsContinueCommand())
m_ProgramIsStopped = false;
}
// Call Action()
command->Action();
// If the command was an action (i.e. no command specified,
// remove it from the queue and run the next command.
// For other commands, this happens in driver's ParseOutput().
if (command->m_Cmd.IsEmpty())
{
RemoveTopCommand(true);
RunQueue();
}
}
--- End code ---
Here's the output:
--- Code: ---DebuggerDriver::RunQueue(): m_DCmds.Count 1, m_Cmd: 'run'
DebuggerDriver::RunQueue(): m_DCmds.Count 1, m_Cmd: 'show language'
DebuggerDriver::RunQueue(): m_DCmds.Count 5, m_Cmd: 'info locals'
DebuggerDriver::RunQueue(): m_DCmds.Count 4, m_Cmd: 'info args' << THIS: Freezes for tens of seconds
DebuggerDriver::RunQueue(): m_DCmds.Count 3, m_Cmd: ''
DebuggerDriver::RunQueue(): m_DCmds.Count 2, m_Cmd: 'bt 30'
DebuggerDriver::RunQueue(): m_DCmds.Count 1, m_Cmd: 'x/64xb 0x0'
DebuggerDriver::RunQueue(): m_DCmds.Count 1, m_Cmd: 'next'
DebuggerDriver::RunQueue(): m_DCmds.Count 1, m_Cmd: 'info locals'
DebuggerDriver::RunQueue(): m_DCmds.Count 4, m_Cmd: 'info args' << Frozen again after "next"
DebuggerDriver::RunQueue(): m_DCmds.Count 3, m_Cmd: ''
DebuggerDriver::RunQueue(): m_DCmds.Count 2, m_Cmd: 'bt 30'
DebuggerDriver::RunQueue(): m_DCmds.Count 1, m_Cmd: 'x/64xb 0x0'
--- End code ---
Now to see what data are returned by GDB, I've added stderr logging to GDB_driver::ParseOutput() as follows:
--- Code: ---void GDB_driver::ParseOutput(const wxString& output)
{
wxLogStderr ErrLog;
wxString tmps;
tmps = ">> GDB_driver::ParseOutput():\n";
tmps << output << "\n << \n";
ErrLog.LogText(tmps);
...
}
--- End code ---
Result:
--- Code: ---DebuggerDriver::RunQueue(): m_DCmds.Count 4, m_Cmd: 'info args'
___FROZEN___100%_CPU_LOAD__HERE___
>> GDB_driver::ParseOutput():
this = 0x555555745170
<<
>> GDB_driver::ParseOutput():
evt = @0x555555b4b780: {<wxEvent> = {<No data fields>}, <wxEventBasicPayloadMixin> = {m_cmdString = {m_impl = L"", m_convertedToChar = {m_str = 0x0, m_len = 0}}, m_commandInt = 131072, m_extraLong = 0}, m_clientData = 0x0, m_clientObject = 0x0, static ms_classInfo = {m_className = 0x7ffff7ca0488 L"wxCommandEvent", m_objectSize = 168, m_objectConstructor = 0x7ffff792dec0 <wxCommandEvent::wxCreateObject()>, m_baseInfo1 = 0x7ffff74b4f80 <wxEvent::ms_classInfo>, m_baseInfo2 = 0x0, static sm_first = 0x7ffff7fc2200 <wxAuiToolBarXmlHandler::ms_classInfo>, m_next = 0x7ffff74b4f00 <wxThreadEvent::ms_classInfo>}}
<<
>> GDB_driver::ParseOutput():
>>>>>>cb_gdb:
<<
DebuggerDriver::RunQueue(): m_DCmds.Count 3, m_Cmd: ''
DebuggerDriver::RunQueue(): m_DCmds.Count 2, m_Cmd: 'bt 30'
--- End code ---
As You can see, this is not a problem with the amount of data to parse.
The process that is consuming 100% CPU time is GDB ... but when I run the the same application from GDB in terminal, the response time to "info args" is nearly zero.
I'm suspecting that this problem is related to Input/Output streams, but for now I don't have the time to analyse and understand the related code.
For sure, this worked flawlessly in the past - the regression happened after ~ svn11200, which I have used for a very long time.
Regards
EDIT:
I've just realized that the GDB response to 'info locals' is received after 'info args' -> this means that something went wrong in the command queue ...
ollydbg:
--- Quote from: tomazzi on November 04, 2023, 08:04:34 pm ---
I'm suspecting that this problem is related to Input/Output streams, but for now I don't have the time to analyse and understand the related code.
For sure, this worked flawlessly in the past - the regression happened after ~ svn11200, which I have used for a very long time.
--- End quote ---
Thanks for the test.
The svn rev11200 is committed in 2017-10-16. That's several years ago. :)
--- Quote ---Author: fuscated <fuscated@2a5c6006-c6dd-42ca-98ab-0921f2732cef>
Date: 2017/10/16 8:12:22
Commit hash: e3f8b41bed48a10059019719544901b0b1994039
* UI: Add 'Enable both' and 'Disable both' menu items in the Options submenu for the files in the project tree
> Most of the times when I use this menu, I want to toggle both options, so
these two new menu items optimise the workflow a bit.
git-svn-id: https://svn.code.sf.net/p/codeblocks/code/trunk@11200 2a5c6006-c6dd-42ca-98ab-0921f2732cef
--- End quote ---
blauzahn:
@tomazzi did not state that it became slow directly after that commit. He just used that version for a long time. So the regression(s) seem to have been introduced between that commit and now. Maybe, that are even several small things that made debugging with gdb on Linux slower and slower.
With our not so small projects I also observe, that debugging on several different Linux systems is painfully slow. It has been like that on trunk for ages. Not only for startup reading in all symbols, but also single stepping. Settings: startup scripts is checked (DISabled), everything else is unchecked (disabled) including watches on args and locals. Its slow even though the project has zero 3rd-party dependency. And sluggishness does neither come from our program nor from my machine (threadripper).
If I had the time, I would inspect cb with https://github.com/KDAB/hotspot and https://github.com/KDE/heaptrack.
blauzahn:
This is cb observed via heaptrack after having run up to a breakpoint, then quit.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version