I have compiled CodeBlocks revision: '13605', with wxWidgets-3.2.6 and when creating a project and viewing the source code the program stops working.
_______________________________________________________________
ASSERT INFO:
/app/include/wx-3.2/wx/vector.h(498): assert "idx < m_size" failed in at().
BACKTRACE:
[1] BrowseTracker::AddEditor(EditorBase*)
[2] BrowseTracker::OnEditorActivated(CodeBlocksEvent&)
[3] BrowseTracker::OnEditorOpened(CodeBlocksEvent&)
[4] Manager::ProcessEvent(CodeBlocksEvent&)
[5] cbEditor::NotifyPlugins(int, int, wxString const&, int, int)
[6] cbEditor::Open(bool)
[7] cbEditor::DoInitializations(wxString const&, LoaderBase*)
[8] cbEditor::cbEditor(wxWindow*, LoaderBase*, wxString const&, EditorColourSet*)
[9] EditorManager::Open(LoaderBase*, wxString const&, int, ProjectFile*)
[10] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[11] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[12] wxEvtHandler::TryHereOnly(wxEvent&)
[13] wxEvtHandler::DoTryChain(wxEvent&)
[14] wxEvtHandler::ProcessEvent(wxEvent&)
[15] wxWindowBase::TryAfter(wxEvent&)
[16] wxWindowBase::TryAfter(wxEvent&)
[17] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[18] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[19] wxMenuBase::SendEvent(int, int)
[20] g_closure_invoke
[21] g_signal_emit_valist
[22] g_signal_emit
[23] gtk_widget_activate
[24] gtk_menu_shell_activate_item
[25] g_signal_emit_valist
[26] g_signal_emit
[27] gtk_main_do_event
[28] g_main_context_iteration
[29] gtk_main_iteration
[30] wxWindow::DoPopupMenu(wxMenu*, int, int)
[31] wxWindowBase::PopupMenu(wxMenu*, int, int)
[32] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[33] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[34] wxEvtHandler::TryHereOnly(wxEvent&)
[35] wxEvtHandler::DoTryChain(wxEvent&)
[36] wxEvtHandler::ProcessEvent(wxEvent&)
[37] wxWindowBase::TryAfter(wxEvent&)
[38] wxWindowBase::TryAfter(wxEvent&)
[39] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[40] wxGenericTreeCtrl::OnMouse(wxMouseEvent&)
[41] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[42] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[43] wxEvtHandler::TryHereOnly(wxEvent&)
[44] wxEvtHandler::ProcessEventLocally(wxEvent&)
[45] wxEvtHandler::ProcessEvent(wxEvent&)
[46] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[47] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[48] g_closure_invoke
[49] g_signal_emit_valist
[50] g_signal_emit
[51] gtk_main_do_event
[52] g_main_loop_run
[53] gtk_main
[54] wxGUIEventLoop::DoRun()
[55] wxEventLoopBase::Run()
[56] wxAppConsoleBase::MainLoop()
[57] wxEntry(int&, wchar_t**)
[58] __libc_start_main
Similar in wxWidgets-3.1.7
----------------------------------------------------------
ASSERT INFO:
/app/include/wx-3.1/wx/vector.h(493): assert "idx < m_size" failed in at().
Looks like commit r13530 (https://sourceforge.net/p/codeblocks/code/13530) broke this and causes the delays reported in this post (https://forums.next.codeblocks.org/index.php/topic,25818.msg176738.html#msg176738).
EDIT: Can you check if reverting r13530 (changes in GetMaxEntries()) fixes the issue? Thank you.
I have been changing from C::B 20.03 to 13605, the program initially worked, but then, I don't know when, it stopped working. I have deleted the user configuration and it no longer breaks. I will try to replicate the error.
Although I was unable to recreate this assert, I added more guards against a possible out-of-bounds error on the BrowseTracker arrays.
CB Revision 13606
I have used CodeBlocks and have not encountered the error again.
May be related to a mismatch between the array size in the config file and the cached value, deleting the config file synced them.
Quote from: Miguel Gimenez on January 31, 2025, 11:07:36 AM
May be related to a mismatch between the array size in the config file and the cached value, deleting the config file synced them.
For my education, what do you mean by "cached value" of the array size.
BrowseTracker reads the array size from the conf file at start up and only at start up. It statically allocates the array size and does not change it.
If more values need to be added than the array size allows, it adds them starting at the top again (circular buffer style).
Am I missing something that could have caused the out-of-bounds error (other than a off-by one error)?
I was talking about these lines in helpers.cpp, currentMaxEntries is caching the value in the configuration:
if (currentMaxEntries) return currentMaxEntries;
...
currentMaxEntries = Manager::Get()->GetConfigManager("BrowseTracker")->ReadInt("JumpViewRowCount", 20);
return currentMaxEntries;
This was just a long shot, because the array was being accessed out of bounds so the array size should be lesser than currentMaxEntries.
Quote from: Miguel Gimenez on January 31, 2025, 07:15:18 PM
I was talking about these lines in helpers.cpp, currentMaxEntries is caching the value in the configuration:
if (currentMaxEntries) return currentMaxEntries;
...
currentMaxEntries = Manager::Get()->GetConfigManager("BrowseTracker")->ReadInt("JumpViewRowCount", 20);
return currentMaxEntries;
This was just a long shot, because the array was being accessed out of bounds so the array size should be lesser than currentMaxEntries.
Thanks, I'll have a look at ever place that's used to make sure it's always used as currentMaxEntries-1 or "For whatever<currentMaxEntries".
I have a question about the svn commit in rev 13606.
Code::Blocks / SVN Repo / Diff of /trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h (https://sourceforge.net/p/codeblocks/code/13606/tree//trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h?diff=51421f1dc431436b6eb31d56:13605)
It looks like this file btswitcherdlg.h does not change anything?
Quote from: ollydbg on February 01, 2025, 02:37:14 PM
I have a question about the svn commit in rev 13606.
Code::Blocks / SVN Repo / Diff of /trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h (https://sourceforge.net/p/codeblocks/code/13606/tree//trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h?diff=51421f1dc431436b6eb31d56:13605)
It looks like this file btswitcherdlg.h does not change anything?
It looks just like that if the end of line is changed; I have no idea how to tell if that is the cause.
Tim S.
Quote from: stahta01 on February 01, 2025, 08:38:14 PM
Quote from: ollydbg on February 01, 2025, 02:37:14 PM
I have a question about the svn commit in rev 13606.
Code::Blocks / SVN Repo / Diff of /trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h (https://sourceforge.net/p/codeblocks/code/13606/tree//trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h?diff=51421f1dc431436b6eb31d56:13605)
It looks like this file btswitcherdlg.h does not change anything?
It looks just like that if the end of line is changed; I have no idea how to tell if that is the cause.
Tim S.
Hi, Tim, thanks, yes, you are right, the EOL has changed.
I just download the old file:
Code::Blocks / SVN Repo / [r13605] /trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h (https://sourceforge.net/p/codeblocks/code/13605/tree/trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h)
and the new file:
Code::Blocks / SVN Repo / [r13606] /trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h (https://sourceforge.net/p/codeblocks/code/13606/tree/trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h)
And I see the new file use the LF, while the old file use CRLF.
Maybe it is a good idea to check if all your source files have the property svn:eol-style=native set to prevent such things ;)