#272 UI unresponsive when debugging

[jmacc]

Sometimes when I try to debug the codeblocks UI becomes unresponsive. It appears that when this happens one of the threads uses 100% cpu. I attached to the process and got stack traces of the thread in question. Through repeated 'break - bt' cycles, it appears to be in one of the following two states.

#0  0x00007f7237a49da3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f723861d777 in wxPipeInputStream::CanRead (this=0x7ec9bb0) at ../src/unix/utilsunx.cpp:304
#2  0x00007f723a678481 in cbTextInputStream::ReadLine (this=this@entry=0x7fff8ba70970) at pipedprocess.cpp:85
#3  0x00007f723a677ed6 in PipedProcess::HasInput (this=0x7ba77e0) at pipedprocess.cpp:191
#4  0x00007f7201839999 in DebuggerGDB::OnIdle (this=<optimized out>, event=...) at debuggergdb.cpp:1963
#5  0x00007f72384c511e in wxAppConsoleBase::CallEventHandler (this=0x27ddf10, handler=0x34d86a0, functor=..., event=...) at ../src/common/appbase.cpp:623
#6  0x00007f7238638282 in wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=<optimized out>, event=...) at ../src/common/event.cpp:1384
#7  0x00007f7238638333 in wxEventHashTable::HandleEvent (this=<optimized out>, event=..., self=self@entry=0x34d86a0) at ../src/common/event.cpp:990
#8  0x00007f723863868d in wxEvtHandler::TryHereOnly (this=0x34d86a0, event=...) at ../src/common/event.cpp:1581
#9  0x00007f72386384a3 in wxEvtHandler::DoTryChain (this=this@entry=0x2b56448, event=...) at ../src/common/event.cpp:1546
#10 0x00007f7238638718 in wxEvtHandler::ProcessEventLocally (this=this@entry=0x2b56448, event=...) at ../src/common/event.cpp:1514
#11 0x00007f7238638765 in wxEvtHandler::ProcessEvent (this=0x2b56448, event=...) at ../src/common/event.cpp:1487
#12 0x00007f72386384f7 in wxEvtHandler::SafelyProcessEvent (this=<optimized out>, event=...) at ../src/common/event.cpp:1605
#13 0x00007f7238f10e9c in wxWindowBase::HandleWindowEvent (this=this@entry=0x2bcc3f0, event=...) at ../src/common/wincmn.cpp:1525
#14 0x00007f7238f10edf in wxWindowBase::SendIdleEvents (this=this@entry=0x2bcc3f0, event=...) at ../src/common/wincmn.cpp:2828
#15 0x00007f7238dfc5af in wxFrame::SendIdleEvents (this=0x2bcc3f0, event=...) at ../src/gtk/frame.cpp:249
#16 0x00007f7238e31dbd in wxAppBase::ProcessIdle (this=<optimized out>) at ../src/common/appcmn.cpp:375
#17 0x00007f7238d8790e in wxApp::DoIdle (this=0x27ddf10) at ../src/gtk/app.cpp:138
#18 0x00007f7238d87a13 in wxapp_idle_callback () at ../src/gtk/app.cpp:107
#19 0x00007f7237488ce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f7237489048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007f723748930a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007f7236c28447 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#23 0x00007f7238d9a145 in wxGUIEventLoop::DoRun (this=0x748adf0) at ../src/gtk/evtloop.cpp:65
#24 0x00007f7238507440 in wxEventLoopBase::Run (this=0x748adf0) at ../src/common/evtloopcmn.cpp:78
#25 0x00007f72384c71fd in wxAppConsoleBase::MainLoop (this=0x27ddf10) at ../src/common/appbase.cpp:334
#26 0x000000000045a424 in CodeBlocksApp::OnRun (this=0x27ddf10) at app.cpp:850
#27 0x00007f723855304d in wxEntry (argc=@0x7f72388e0190: 1, argv=<optimized out>) at ../src/common/init.cpp:495

#0  0x00007f7238006c6f in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find(wchar_t const*, unsigned long, unsigned long) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007f7201857e74 in find (__pos=0, __str=L"cb_gdb:", this=0x7f7201a94d70 <GDB_driver::ParseOutput(wxString const&)::buffer>)
    at /usr/include/c++/4.8/bits/basic_string.h:1848
#2  find (nStart=0, str=..., this=0x7f7201a94d70 <GDB_driver::ParseOutput(wxString const&)::buffer>) at /usr/include/wx-3.0/wx/string.h:3084
#3  Find (sub=..., this=0x7f7201a94d70 <GDB_driver::ParseOutput(wxString const&)::buffer>) at /usr/include/wx-3.0/wx/string.h:2234
#4  First (str=..., this=0x7f7201a94d70 <GDB_driver::ParseOutput(wxString const&)::buffer>) at /usr/include/wx-3.0/wx/string.h:2417
#5  GDB_driver::ParseOutput (this=0x7ba6150, output=...) at gdb_driver.cpp:819
#6  0x00007f720183b30d in DebuggerGDB::OnGDBOutput (this=0x34d86a0, event=...) at debuggergdb.cpp:1831
#7  0x00007f72384c511e in wxAppConsoleBase::CallEventHandler (this=0x27ddf10, handler=0x34d86a0, functor=..., event=...) at ../src/common/appbase.cpp:623
#8  0x00007f7238638282 in wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=<optimized out>, event=...) at ../src/common/event.cpp:1384
#9  0x00007f7238638333 in wxEventHashTable::HandleEvent (this=<optimized out>, event=..., self=self@entry=0x34d86a0) at ../src/common/event.cpp:990
#10 0x00007f723863868d in wxEvtHandler::TryHereOnly (this=this@entry=0x34d86a0, event=...) at ../src/common/event.cpp:1581
#11 0x00007f7238638703 in TryBeforeAndHere (event=..., this=this@entry=0x34d86a0) at ../include/wx/event.h:3671
#12 wxEvtHandler::ProcessEventLocally (this=this@entry=0x34d86a0, event=...) at ../src/common/event.cpp:1514
#13 0x00007f7238638765 in wxEvtHandler::ProcessEvent (this=0x34d86a0, event=...) at ../src/common/event.cpp:1487
#14 0x00007f7238639783 in wxEvtHandler::ProcessPendingEvents (this=0x34d86a0) at ../src/common/event.cpp:1351
#15 0x00007f72384c8cd7 in wxAppConsoleBase::ProcessPendingEvents (this=0x27ddf10) at ../src/common/appbase.cpp:520
#16 0x00007f7238d87902 in wxApp::DoIdle (this=0x27ddf10) at ../src/gtk/app.cpp:136
#17 0x00007f7238d87a13 in wxapp_idle_callback () at ../src/gtk/app.cpp:107
#18 0x00007f7237488ce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f7237489048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f723748930a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007f7236c28447 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#22 0x00007f7238d9a145 in wxGUIEventLoop::DoRun (this=0x748adf0) at ../src/gtk/evtloop.cpp:65
#23 0x00007f7238507440 in wxEventLoopBase::Run (this=0x748adf0) at ../src/common/evtloopcmn.cpp:78
#24 0x00007f72384c71fd in wxAppConsoleBase::MainLoop (this=0x27ddf10) at ../src/common/appbase.cpp:334
#25 0x000000000045a424 in CodeBlocksApp::OnRun (this=0x27ddf10) at app.cpp:850
#26 0x00007f723855304d in wxEntry (argc=@0x7f72388e0190: 1, argv=<optimized out>) at ../src/common/init.cpp:495

I'm running a build from revision 10563.

[jmacc]

Sorry for the formatting above. UI is interpreting something in the stack trace.

[Teodor Petrov]

Known problem. Sometimes gdb just returns large number of lines as the result of some commands (print myVector for example). There is nothing we can do about it in the current implementation.

[ollydbg]

I formatted the call stack texts.

[ollydbg]

You can use the command:

set print elements number-of-elements

to limit the element number.
See GDB's manual. Print Settings - Debugging with GDB

[jmacc]

Root cause, at least in my case seems to be this.

https://sourceware.org/bugzilla/show_bug.cgi?id=17139

'set print elements' doesn't seem to help. gdb seems to want to process all the invalid memory even if it's only going to display some subset of the (uninitialzed) data.

[Teodor Petrov]

Yep, this isn't something we could fix in the current code. :(

[Andrew Cottrell]

@ fuscated Is this still something that cannot be fixed in the current code?

[Teodor Petrov]

Yes, it cannot be fixed, because we're parsing text output and if the printer wants to print the whole memory, because it has read that size is uint32(-1) we cannot do much.

The only proper fix is working on the gdb-mi debugger or integrating lldb...

[jmacc]

I have not looked at this in any detail at all but VSC doesn't seem to have this issue, fwiw.

[Teodor Petrov]

@jmacc What is VSC? If it is Visual studio Code then it uses the gdb-mi interface, as far as I know.

[jmacc]

@fuscated Yes, Visual Studio Code.