News:

The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .

Main Menu

CodeBlocks revision: '13605', breaks when opening a file (LINUX)

Started by dthu, January 28, 2025, 03:57:03 AM

Previous topic - Next topic

dthu

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



dthu

Similar in wxWidgets-3.1.7
----------------------------------------------------------
ASSERT INFO:
/app/include/wx-3.1/wx/vector.h(493): assert "idx < m_size" failed in at().


Miguel Gimenez

#2
Looks like commit r13530 broke this and causes the delays reported in this post.

EDIT: Can you check if reverting r13530 (changes in GetMaxEntries()) fixes the issue? Thank you.

dthu

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.

Pecan

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

dthu

I have used CodeBlocks and have not encountered the error again.

Miguel Gimenez

May be related to a mismatch between the array size in the config file and the cached value, deleting the config file synced them.

Pecan

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)?

Miguel Gimenez

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.

Pecan

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".

ollydbg

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

stahta01

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

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.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

ollydbg

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

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

and the new file:

Code::Blocks / SVN Repo / [r13606] /trunk/src/plugins/contrib/BrowseTracker/btswitcherdlg.h

And I see the new file use the LF, while the old file use CRLF.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

sodev

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 ;)