Code::Blocks

User forums => General (but related to Code::Blocks) => Topic started by: Pecan on January 24, 2006, 12:52:53 am

Title: Is this a memory leak?
Post by: Pecan on January 24, 2006, 12:52:53 am
I know this is probably a stupid question, but is wxString
freed in the following example? Or is there a leak.

Something like this happend to me during the recent
settings scheme revamp.

Code: [Select]
class Aclass
{
   wxString* MyStringPtr;
   ~Aclass(){}
}
Aclass::Aclass()
{
    MyStringPtr = new wxString;
}

This is worrying me.

Thanks
pecan
Title: Re: Is this a memory leak?
Post by: 280Z28 on January 24, 2006, 12:56:19 am
It's not freed.
Title: Re: Is this a memory leak?
Post by: rickg22 on January 24, 2006, 12:58:02 am
Hint: Pointers to objects (wxString* m_pString) should always be allocated and deallocated manually on the constructor and destructor.
Direct objects (wxString m_String) are handled automatically.
Title: Re: Is this a memory leak?
Post by: killerbot on January 24, 2006, 01:14:20 am
a leak it is !


@Rick, not everything allocated by the user has to be freed by the user, especially with wxWidgets and menus, the ownership is tranfered in those cases.
So it's good to realize when ownership is transfered.
I for one, sureley doesn't know all the transfers within wx.  :(
Title: Re: Is this a memory leak?
Post by: thomas on January 24, 2006, 01:38:23 am
I for one, sureley doesn't know all the transfers within wx.  :(
If you give it away, you don't own it any more. That's a 99% good rule (with very very few exceptions).
Title: Re: Is this a memory leak?
Post by: Pecan on January 24, 2006, 02:13:37 am
Whos responsibility is it to delete all the stuff used
to make dialogs, menus etc. Like:

EDIT: I screwed up the coloration, but you get the idea.


// ----------------------------------------------------------------------------
void wxKeyConfigPanel::BuildCtrls()
// ----------------------------------------------------------------------------
{
    if (m_nBuildMode & wxKEYBINDER_USE_TREECTRL) {

      // use a wxTreeCtrl to show the commands hierarchy
      m_pCommandsTree = new wxTreeCtrl(this, wxKEYBINDER_COMMANDS_BOX_ID, wxDefaultPosition,
                           wxDefaultSize, wxTR_HAS_BUTTONS | wxSUNKEN_BORDER);
   } else {

      // use a combobox + a listbox
      m_pCommandsList = newnew wxListBox(this, wxKEYBINDER_COMMANDS_BOX_ID, wxDefaultPosition,
                           wxDefaultSize, 0, NULL);
      m_pCategories = new wxComboBox(this, wxKEYBINDER_CATEGORIES_ID,
                        wxEmptyString, wxDefaultPosition, wxDefaultSize,
                        0, NULL, wxCB_READONLY);
   }

    m_pKeyField = new wxKeyMonitorTextCtrl(this, wxKEYBINDER_KEY_FIELD_ID);
    m_pBindings = new wxListBox(this, wxKEYBINDER_BINDINGS_BOX_ID);

    m_pAssignBtn = new wxButton(this, wxKEYBINDER_ASSIGN_KEY_ID, wxT("&Add"));
    m_pRemoveBtn = new wxButton(this, wxKEYBINDER_REMOVE_KEY_ID, wxT("&Remove"));
    m_pRemoveAllBtn =new new wxButton(this, wxKEYBINDER_REMOVEALL_KEY_ID, wxT("Remove all"));

   m_pCurrCmdField = newnew wxStaticText(this, -1, wxT(""), wxDefaultPosition,
      wxSize(-1, 20), wxSIMPLE_BORDER | wxST_NO_AUTORESIZE | wxALIGN_CENTRE);

   // we won't make it white because it must be clear to the user that this
   // is not a text control...
   m_pCurrCmdField->SetBackgroundColour(wxColour(200, 200, 200));

#ifdef __WXGTK__
    m_pDescLabel = newnew wxTextCtrl(this, -1, wxT(""), wxDefaultPosition,
                         wxDefaultSize, wxTE_READONLY | wxTE_MULTILINE);
#else
   m_pDescLabel =newnew wxStaticText(this, -1, wxT(""), wxDefaultPosition,
      wxSize(-1, 40), wxSIMPLE_BORDER | wxST_NO_AUTORESIZE);
   m_pDescLabel->SetBackgroundColour(wxColour(255, 255, 255));
#endif

   // KEY PROFILES
   // create the key profiles combobox & panel
   m_bEnableKeyProfiles = TRUE;

   // the style of a combobox must be set at the beginning:
   // you cannot change the wxCB_READONLY flag presence later...
   // VERY IMPORTANT: *NEVER* ADD THE CB_SORT STYLE:
   // IT WOULD GIVE US GREAT PROBLEMS WHEN EDITING THE KEYPROFILE...
   long style = (m_nBuildMode & wxKEYBINDER_ENABLE_PROFILE_EDITING) ? 0 : wxCB_READONLY;
   m_pKeyProfiles = newnew wxComboBox(this, wxKEYBINDER_KEYPROFILES_ID,
                        wxEmptyString, wxDefaultPosition, wxDefaultSize,
                        0, NULL, style);

   wxSizer *sizer = newnew wxBoxSizer(wxHORIZONTAL);
   sizer->Add(m_pKeyProfiles, 6, wxGROW);

   if (m_nBuildMode & wxKEYBINDER_SHOW_ADDREMOVE_PROFILE) {

      // create the Add & remove profile buttons
      sizer->Add(newnew wxButton(this, wxKEYBINDER_ADD_PROFILEBTN_ID, wxT("Add new")), 0,
                     wxGROW | wxLEFT | wxRIGHT | wxBOTTOM, 5);
      sizer->Add(newnew wxButton(this, wxKEYBINDER_REMOVE_PROFILEBTN_ID, wxT("Remove")), 0,
                     wxGROW | wxLEFT | wxRIGHT | wxBOTTOM, 5);
   }

   m_pKeyProfilesSizer = newnew wxBoxSizer(wxVERTICAL);
   m_pKeyProfilesSizer->Add(newnew wxStaticText(this, -1, wxT("Key profile:")), 0, wxGROW | wxALL, 5);
   m_pKeyProfilesSizer->Add(sizer, 0, wxGROW | wxLEFT | wxRIGHT, 5);
   m_pKeyProfilesSizer->Add(newnew wxStaticLine(this, -1), 0, wxGROW | wxALL, 5);
}
Title: Re: Is this a memory leak?
Post by: sethjackson on January 24, 2006, 03:16:42 am
Whoa 5pt font size I can't even read that......  :P

Check these out.

http://wxforum.shadonet.com/viewtopic.php?t=4540
http://wxforum.shadonet.com/viewtopic.php?t=5719

http://www.wxwidgets.org/manuals/2.6.2/wx_windowdeletionoverview.html#windowdeletionoverview
Title: Re: Is this a memory leak?
Post by: thomas on January 24, 2006, 08:38:05 am
Quote
Whos responsibility is it to delete all the stuff used
to make dialogs, menus etc. Like:
You give those objects away, so they aren't yours :)
Title: Re: Is this a memory leak?
Post by: killerbot on January 24, 2006, 08:59:55 am
we just need to learn wx that well, that we know, when we give it away or not. Read the wx manual from cover to cover.  8)
Title: Re: Is this a memory leak?
Post by: thomas on January 24, 2006, 09:48:03 am
Oh, it is not that bad really:
http://www.google.com/search?q=%22responsible+for+deleting%22+site%3Ahttp%3A%2F%2Fwww.wxwidgets.org%2Fmanuals%2F2.6.2&btnG=Suche&meta=
http://www.google.com/search?hl=de&q=ownership+site%3Ahttp%3A%2F%2Fwww.wxwidgets.org%2Fmanuals%2F2.6.2&btnG=Suche&lr=

The only important one may be the one in wxProcess, but you will likely not need to use that anyway. The one in wxMenu only applies if you manually detach it (you never do that, so forget it), and the others are not important for different reasons (mostly because we either don't use them at all, or because we do use them globally, so you don't have to worry about freeing them).

It may of course be possible that this search missed one or two special cases, but that does not matter, either. The worst thing to happen is that you waste a few hundred bytes of memory... it might matter if it were about a thousand objects, but one leaked object really is no problem.
The only category of objects which we allocate in thousands is GUI components, and we know that we don't own these.
Title: Re: Is this a memory leak?
Post by: takeshi miya on January 24, 2006, 01:02:14 pm
but one leaked object really is no problem.

And at that time is where Valgrind comes in handy. Is there anything remotely simmilar for Windows?
Title: Re: Is this a memory leak?
Post by: Ceniza on January 24, 2006, 02:40:45 pm
Quote from: Takeshi Miya
And at that time is where Valgrind comes in handy. Is there anything remotely simmilar for Windows?

Rational Purify (http://www-306.ibm.com/software/awdtools/purify/) ($780)
Title: Re: Is this a memory leak?
Post by: killerbot on January 24, 2006, 02:55:51 pm
Compuware Numega DevPartner (for M$ DevStudio)
Title: Re: Is this a memory leak?
Post by: Michael on January 24, 2006, 03:05:01 pm
Quote from: Takeshi Miya
And at that time is where Valgrind comes in handy. Is there anything remotely simmilar for Windows?

Rational Purify (http://www-306.ibm.com/software/awdtools/purify/) ($780)

Yes, but you can get a special license (I do not remember exactly which one :() and then get it for free (and other software from IBM too) :D.

Michael

[EDIT] Purify is available as trial (it is a bit annoying to go throught the process :(). Anyway, you can get it for free if you are accepted by the IBM Scholars Programm (which is not bad :)).
Title: Re: Is this a memory leak?
Post by: Michael on January 24, 2006, 03:08:58 pm
May be this topic (http://forums.codeblocks.org/index.php?topic=1094.0) would be worth.

There are some posts in this forum about memory leaks. May be it could be interesting to have a look at them.

Michael
Title: Re: Is this a memory leak?
Post by: 280Z28 on January 24, 2006, 03:42:12 pm
When my copy of Code::Blocks is running in debug mode in Visual Studio, it dumps a list of all non-freed objects at exit including size of the allocation and the filename and line number where they were allocated.  :shock: Some feature of wxWidgets that came out in the VS debugger??
Title: Re: Is this a memory leak?
Post by: takeshi miya on January 24, 2006, 06:06:54 pm
Seems I forgot to add the word "opensource" and "free" to it. :lol:

When my copy of Code::Blocks is running in debug mode in Visual Studio, it dumps a list of all non-freed objects at exit including size of the allocation and the filename and line number where they were allocated.  :shock: Some feature of wxWidgets that came out in the VS debugger??

Seems you have noticed it. :) The redefinition of operator new (which thomas likes to ditch very often :P) haves a real and very useful purpose.
And it's only enabled when you are in debug build. But anyways, you can disable it by settings wxUSE_DEBUG_NEW_ALWAYS to 0 in setup.h.

For wxDebugContext to do its work, the new and delete operators for wxObject have been redefined to store extra information about dynamically allocated objects (but not statically declared objects). This slows down a debugging version of an application, but can find difficult-to-detect memory leaks (objects are not deallocated), overwrites (writing past the end of your object) and underwrites (writing to memory in front of the object).


Here's something very useful about the class wxDebugContext:

Quote
wxDebugContext is a class for performing various debugging and memory tracing operations.

This class has only static data and function members, and there should be no instances. Probably the most useful members are SetFile (for directing output to a file, instead of the default standard error or debugger output); Dump (for dumping the dynamically allocated objects) and PrintStatistics (for dumping information about allocation of objects). You can also call Check to check memory blocks for integrity.

Here's an example of use. The SetCheckpoint ensures that only the allocations done after the checkpoint will be dumped.

Code: C++
  1.   wxDebugContext::SetCheckpoint();
  2.  
  3.   wxDebugContext::SetFile("c:\\temp\\debug.log");
  4.  
  5.   wxString *thing = new wxString;
  6.  
  7.   char *ordinaryNonObject = new char[1000];
  8.  
  9.   wxDebugContext::Dump();
  10.   wxDebugContext::PrintStatistics();
  11.