I just ran a little test on Linux using valgrind (www.valgrind.org). I'm using revision 1886 without any active plugin. I just opened Code::Blocks, openend the keybinder-project (without any open editor, just the start-here-page), closed it and then closed Code::Blocks.
The first thing I then noticed was the use of an unitialised variable:
==7212== Conditional jump or move depends on uninitialised value(s)
==7212== at 0x1B9EFA26: CompileTargetBase::SetOptionRelation(OptionsRelationType, OptionsRelation) (compiletargetbase.cpp:116)
==7212== by 0x1BA7BA93: ProjectLoader::DoBuildTargetOptions(TiXmlElement*, ProjectBuildTarget*) (projectloader.cpp:429)
==7212== by 0x1BA7C4EE: ProjectLoader::DoBuildTarget(TiXmlElement*) (projectloader.cpp:289)
==7212== by 0x1BA7C6BA: ProjectLoader::DoBuild(TiXmlElement*) (projectloader.cpp:267)
==7212== by 0x1BA7CEE0: ProjectLoader::Open(wxString const&) (projectloader.cpp:90)
==7212== by 0x1B9D9721: cbProject::Open() (cbproject.cpp:269)
==7212== by 0x1B9DA85B: cbProject::cbProject(wxString const&) (cbproject.cpp:75)
==7212== by 0x1BA8B084: ProjectManager::LoadProject(wxString const&, bool) (projectmanager.cpp:616)
==7212== by 0x807DA88: MainFrame::DoOpenProject(wxString const&, bool) (main.cpp:1122)
==7212== by 0x807DFD4: MainFrame::OpenGeneric(wxString const&, bool) (main.cpp:1089)
==7212== by 0x8087ECB: MainFrame::OnStartHereLink(wxCommandEvent&) (main.cpp:1339)
==7212== by 0x1C35848A: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.0.0)
This can be solved with this patch:
Index: src/sdk/compiletargetbase.cpp
===================================================================
--- src/sdk/compiletargetbase.cpp (revision 1886)
+++ src/sdk/compiletargetbase.cpp (working copy)
@@ -34,7 +34,7 @@
m_CompilerIdx(0)
{
//ctor
- for (int i = 0; i < 4; ++i)
+ for (int i = 0; i < ortLast; ++i)
m_OptionsRelation[i] = orAppendToParentOptions;
// default "make" commands
And yes, valgringd reports also memory-leaks. Some about wxString, but also some about Code::Blocks itself. (See the attachment for a list)
Anyway, I fear that this is only the tip of the iceberg...
[attachment deleted by admin]
I just fixed two of the memory leaks valgrind discovered (patch is at sf.net - #1417376 (https://sourceforge.net/tracker/index.php?func=detail&aid=1417376&group_id=126998&atid=707418)).
However, there still remain a lot memory leaks. Three of them look as they could easily be fixed if there were not those damn wxArrays:
6176 bytes in 8 blocks are definitely lost in loss record 130 of 148
==9113== at 0x1B90524A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==9113== by 0x1BA6D092: ProjectFile::ProjectFile(cbProject*) (hashmap.h:101)
==9113== by 0x1B9D7778: cbProject::AddFile(int, wxString const&, bool, bool, unsigned short) (blockallocated.h:147)
==9113== by 0x1BA78995: ProjectLoader::DoUnits(TiXmlElement*) (projectloader.cpp:644)
==9113== by 0x1BA7CFEC: ProjectLoader::Open(wxString const&) (projectloader.cpp:103)
==9113== by 0x1B9D9721: cbProject::Open() (cbproject.cpp:273)
==9113== by 0x1B9DA85B: cbProject::cbProject(wxString const&) (cbproject.cpp:79)
==9113== by 0x1BA8B0C4: ProjectManager::LoadProject(wxString const&, bool) (projectmanager.cpp:622)
==9113== by 0x807DAE8: MainFrame::DoOpenProject(wxString const&, bool) (main.cpp:1122)
==9113== by 0x807E034: MainFrame::OpenGeneric(wxString const&, bool) (main.cpp:1089)
==9113== by 0x8087F2B: MainFrame::OnStartHereLink(wxCommandEvent&) (main.cpp:1339)
==9113== by 0x1C35848A: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.0.0)
4376 (240 direct, 4136 indirect) bytes in 12 blocks are definitely lost in loss record 103 of 148
==9113== at 0x1B904603: operator new(unsigned) (in /usr/lib/valgrind/vgpreload_memcheck.so)
==9113== by 0x1BA68D4C: PluginManager::LoadPlugin(wxString const&) (pluginmanager.cpp:197)
==9113== by 0x1BA696C9: PluginManager::ScanForPlugins(wxString const&) (pluginmanager.cpp:94)
==9113== by 0x8071DAE: MainFrame::ScanForPlugins() (main.cpp:700)
==9113== by 0x807C4F9: MainFrame::MainFrame(wxWindow*) (main.cpp:440)
==9113== by 0x8062CB8: CodeBlocksApp::InitFrame() (app.cpp:229)
==9113== by 0x8064147: CodeBlocksApp::OnInit() (app.cpp:412)
==9113== by 0x8065080: wxAppConsole::CallOnInit() (app.h:87)
==9113== by 0x1C39C8AF: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.0.0)
==9113== by 0x1C39CC1B: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.6.so.0.0.0)
==9113== by 0x80605E9: main (app.cpp:87)
==9113== 1600 (80 direct, 1520 indirect) bytes in 4 blocks are definitely lost in loss record 112 of 148
==9113== at 0x1B904603: operator new(unsigned) (in /usr/lib/valgrind/vgpreload_memcheck.so)
==9113== by 0x1BA68FD1: PluginManager::LoadPlugin(wxString const&) (pluginmanager.cpp:229)
==9113== by 0x1BA696C9: PluginManager::ScanForPlugins(wxString const&) (pluginmanager.cpp:94)
==9113== by 0x8071DAE: MainFrame::ScanForPlugins() (main.cpp:700)
==9113== by 0x807C4F9: MainFrame::MainFrame(wxWindow*) (main.cpp:440)
==9113== by 0x8062CB8: CodeBlocksApp::InitFrame() (app.cpp:229)
==9113== by 0x8064147: CodeBlocksApp::OnInit() (app.cpp:412)
==9113== by 0x8065080: wxAppConsole::CallOnInit() (app.h:87)
==9113== by 0x1C39C8AF: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.0.0)
==9113== by 0x1C39CC1B: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.6.so.0.0.0)
==9113== by 0x80605E9: main (app.cpp:87)
(Note: I noticed that the line-numbers valgrind prints are not always correct - but they seem to be at least close to the problematic line.)
I'm not really familiar with wxArrays (Why are we even using them in these cases? Shouldn't be the STL-containers be good enough?), so I didn't try to solve this leaks. I looks as we need to iterate through the array in the destructor of the class that owns this array and call delete for every entry of the array.
Anyway, especially these problems could have been easily avoided if smart pointers were used (Well, someone said, raw pointers in containers are evil. First I didn't believe it but during the last projects I was working on I learned that this is really true... :? ), but changing this now would possible be a lot of work.
Shouldn't be the STL-containers be good enough?), so I didn't try to solve this leaks. I looks as we need to iterate through the array in the destructor of the class that owns this array and call delete for every entry of the array.
Half C::B is written with wx containers, and the other half with stl containers.
That's mostly because historical reasons: wx2.x adviced to try not use the STL at all, because compilers could not support well the STL/templates.
But we are in 2006 now, and the situation has changed (the compilers improved a lot), so that advice is no longer true.
In fact, I hope there will be a transition to use STL whenever possible, because wxWidgets 3.0 (aka wxTNG) will change radically to that way. And it has been said that a wxWidgets <-> boost cooperation is high likely to be done, so wx will use STL and boost instead of reinvent the well. It has been said that even the wxTNG will be sent to boost as a proposal to the GUI library. :D
Anyway, especially these problems could have been easily avoided if smart pointers were used (Well, someone said, raw pointers in containers are evil. First I didn't believe it but during the last projects I was working on I learned that this is really true... :? ), but changing this now would possible be a lot of work.
Agreed, if one wants to use smart pointers (boost::shared_ptr) right now with wxWidgets, check this (http://wxforum.shadonet.com/viewtopic.php?t=4947): http://wxforum.shadonet.com/viewtopic.php?t=4947
I modified the boost files, so that it will automatically call Destroy instead of delete for objects derived with wxWindow. So now, when you write code, it will automatically call Destroy:
wxWidgets example:
#include <boost/shared_ptr.hpp>
typedef boost::shared_ptr wx_ptr;
wx_ptr<wxMessageDialog> ptr(new wxMessageDialog(...));
I think there could be done in C::B a transition from wx-containers to stl-containers, and pointers to smart-pointers, either slowly, or all at the same time, creating a new branch, just like when we made the UNICODE transition.
That will for sure create a C::B with almost 0 probability of having mem-leaks, and at the same time contributors like Der Meister can provide a patch because he understands stl containers but not wx containers. :D