I'm using Code::Blocks 16.01 on Debian 8 (jessie) 64-bit, and I frequently get random crashes with such errors:
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
codeblocks: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Does anyone know anything about this error and possibly how to avoid it?
Disable symbol browser in the settings of the code completion plugin.
Thanks, disabled it and will see how it goes.
Just a side note, when I went to Settings > Editor... > Code completion, Symbols Browser tab and checked "Disable symbols browser", clicked OK I got:
ASSERT INFO:
../src/common/wincmn.cpp(1517): assert "Assert failure" failed in RemoveEventHandler(): where has the event handler gone?
BACKTRACE:
[1] wxWindowBase::RemoveEventHandler(wxEvtHandler*)
[2] wxKeyBinder::DetachAll()
[3] wxKeyProfile::~wxKeyProfile()
[4] cbKeyBinder::OnKeyConfigDialogDone(MyDialog*)
[5] non-virtual thunk to wxTextCtrlBase::SetValue(wxString const&)
[6] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[7] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[8] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[9] wxEvtHandler::TryHereOnly(wxEvent&)
[10] wxEvtHandler::ProcessEventLocally(wxEvent&)
[11] wxEvtHandler::ProcessEvent(wxEvent&)
[12] wxWindowBase::TryAfter(wxEvent&)
[13] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[14] g_signal_emit_valist
[15] g_signal_emit
[16] g_signal_emit_valist
[17] g_signal_emit
[18] g_closure_invoke
[19] g_signal_emit_valist
[20] g_signal_emit
[21] gtk_propagate_event
[22] gtk_main_do_event
[23] g_main_context_dispatch
[24] g_main_loop_run
[25] gtk_main
[26] wxGUIEventLoop::DoRun()
[27] wxEventLoopBase::Run()
[28] wxDialog::ShowModal()
[29] wxStringTokenizer::~wxStringTokenizer()
[30] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[31] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[32] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[33] wxEvtHandler::TryHereOnly(wxEvent&)
[34] wxEvtHandler::DoTryChain(wxEvent&)
[35] wxEvtHandler::ProcessEvent(wxEvent&)
[36] wxWindowBase::TryAfter(wxEvent&)
[37] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[38] wxMenuBase::SendEvent(int, int)
[39] g_closure_invoke
[40] g_signal_emit_valist
[41] g_signal_emit
[42] gtk_widget_activate
[43] gtk_menu_shell_activate_item
[44] g_closure_invoke
[45] g_signal_emit_valist
[46] g_signal_emit
[47] gtk_propagate_event
[48] gtk_main_do_event
[49] g_main_context_dispatch
[50] g_main_loop_run
[51] gtk_main
[52] wxGUIEventLoop::DoRun()
[53] wxEventLoopBase::Run()
[54] wxAppConsoleBase::MainLoop()
[55] wxEntry(int&, wchar_t**)
[56] __libc_start_main
I know about this problem, but unfortunately it doesn't happen every time.