If you are on windows you may know the problem:
Debugging with GDB is PAINFULLY slow...
I finally have found a 10 year old workaround: https://stackoverflow.com/questions/27380443/why-is-gdb-so-slow-in-windows
To use this in codeblocks:
1) Settings-> Environment-> Environment Variables->Add:
Key = _NO_DEBUG_HEAP
Value = 1
2) Ok
3) Project->Properties->EnvVars option->Select environment....->defaukt
For me this is speeding up the gdb startup fo 200%
I meet the same issue before. Especially if you code has many "new" and "delete" function calls, GDB will be quite slow.
Setting such environment variable will speed up the debugee a lot!
Step 3 generates an "EnVars Plugin Warning, The project contained a reference to an envvar set ('default') that could not be found".
With my latest local build I do not get the warnings when setting up step 3, but if I go back into Project->Properties I get the warning. The EnvVars options tab shows the correct data as does the Settings-> Environment-> Environment Variables dialog data.
The warning is also shown when I go back into the Settings-> Environment-> Environment Variables and exit (it shows 3 times...).
The warning dialog info is:
[Window Title]
EnvVars Plugin Warning
[Content]
Warning: The project contained a reference to an envvar set
('default') that could not be found.
[OK]
Hope this extra info is of some help.
I think the EnvVars plugin is buggy, whatever set you select in Project->Properties->EnvVars options is never found.
This patch fixes it for me...
No idea why the old code was there, it made no sense if a default set was set...
Index: src/plugins/contrib/envvars/envvars_common.cpp
===================================================================
--- src/plugins/contrib/envvars/envvars_common.cpp (revision 12529)
+++ src/plugins/contrib/envvars/envvars_common.cpp (working copy)
@@ -229,8 +229,8 @@
set_path.Empty();
ConfigManager *cfg = Manager::Get()->GetConfigManager(_T("envvars"));
- if (!cfg || set_path.IsEmpty())
- return set_path;
+ if (!cfg)
+ return wxString();
if (!check_exists)
return _T("/sets/")+set_name;
I did a local build with the patch and the warnings no longer occur.
@bluehazzard, do you plan to commit the patch or should someone post a ticket so this is not lost?. Currently the envvars plugin does not work at all with projects, so IMHO it is a major bug.
Quote from: Miguel Gimenez on October 12, 2021, 07:17:55 PM
@bluehazzard, do you plan to commit the patch or should someone post a ticket so this is not lost?. Currently the envvars plugin does not work at all with projects, so IMHO it is a major bug.
Have you found other problems too?
While the patch fixes the warning about set not found, the plugin does not set the specified variables. I have written a test console program that prints the value of an environment variable called TEST_VAR, and created two sets with different values for the variable; whatever set you select in Project Options, the printed value is the same.
#include <windows.h>
#include <stdio.h>
int main()
{
char Buffer[256];
const DWORD res = GetEnvironmentVariable("TEST_VAR", Buffer, sizeof(Buffer));
if (!res)
{
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, GetLastError(), MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), Buffer, sizeof(Buffer), NULL);
printf("Error %s", Buffer);
}
else
printf("TEST_VAR = %s", Buffer);
return 0;
}
The expected behaviour is: the plugin sets the variable to the value indicated in the specified set
EDIT: if you close the project and reopen it, you get again the "set not found" warnings. I will study this deeper and create a ticket.
Slow debugging in codeblock is this normal! The debugger code itself is very slow, all windows: watch, dissasemble, register, etc use a complete update of their area, even if they only need to update one symbol. Moreover, the used wxwidget has fatal flaws, which, after a while, practically lead to the debugger freezing. That is, at first the debugger works quickly, but then, it starts to slow down significantly due to errors in wxwidget.
Wxwidget has different functions that work in the same way or with minimal differences, replacing resource-intensive functions with less resource-intensive ones will lead to less memory leaks and stabilize the situation.
I have just created ticket 1145 (https://sourceforge.net/p/codeblocks/tickets/1145/) fixing the EnvVars plugin