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:
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();
}
}
Here's the output:
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'
Now to see what data are returned by GDB, I've added stderr logging to GDB_driver::ParseOutput() as follows:
void GDB_driver::ParseOutput(const wxString& output)
{
wxLogStderr ErrLog;
wxString tmps;
tmps = ">> GDB_driver::ParseOutput():\n";
tmps << output << "\n << \n";
ErrLog.LogText(tmps);
...
}
Result:
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'
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 ...
