Author Topic: Find many new added patches to fix memory leaks  (Read 4840 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Find many new added patches to fix memory leaks
« on: August 12, 2009, 05:00:12 pm »
Hi, CB devs, I accidentally find many patches to fix memory leaks in CB. These patches were add by a BerliOS user named "techy". They are really valuable!

I hope you can give the attention. Thanks. :D

By the way, Is there any good memory leak detector under MinGW?

I have tried this one : http://wyw.dcweb.cn/leakage.htm

But it will blindly report many memory leaks under wxWidgets, because every wxWidgets window was created by "new" expression, but they will be released by the wxWidgets core implicitly( the memory detector can't catch all the "delete" called by the wxWidgets-core)  :(.


« Last Edit: August 12, 2009, 05:03:50 pm by 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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9723
Re: Find many new added patches to fix memory leaks
« Reply #1 on: August 12, 2009, 05:06:33 pm »
I hope you can give the attention. Thanks. :D
Action taken.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Find many new added patches to fix memory leaks
« Reply #2 on: August 12, 2009, 07:55:12 pm »
Patch #1 does not work for me.

Patch #2 adds a wait which I don't understand and defers loading of editor contents to after the editor is initialised, which again I don't understand in the context of "leak". Deferring the load to the very end also makes asynchronous loading in a background thread silly... it would be more efficient then to just load the data in the main thread.

Patch #3 can't say anything about.... code completion.

Patch #4 is technically correct, but does not really improve the application. It explicitely destroys the DDE connection object before terminating the process. There is no leak either way, as the application terminates immediately afterwards.

Patch #5 looks ok

Patch #6 looks ok for consistence, though it is questionable if unregistering any of the event handlers in Manager::~Manager is actually a win (as the process terminates right after Manager is destroyed)

Patch #7 does not work for me.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."