« previous next »
Pages: 1 [2] 3 4 5 6 7   Go Down

Author Topic: HUGE MEMORY LEAK pinpointed!  (Read 63607 times)

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: HUGE MEMORY LEAK pinpointed!
« Reply #15 on: June 20, 2007, 05:32:58 pm »
Couple of Intel's tools are now free for Non-commercial use on Linux. Can anyone tell us whether Intel VTune Performance Analyser be used to detect Memory Leak or so? :)
Logged
Be a part of the solution, not a part of the problem.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #16 on: June 20, 2007, 05:38:54 pm »
Quote from: thomas on June 20, 2007, 05:22:15 pm
it would be better to use the FileManager for loading, anyway.

Except this function is low level. The Todo plugin, for example, distinguishes between open files and in-disk files. File manager only opens one copy....  :o Oh, I get your point now.

So, should I change delete for delete[] in next SVN? er, I read the link. I'll do it tonight.
« Last Edit: June 20, 2007, 05:41:07 pm by rickg22 »
Logged

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: HUGE MEMORY LEAK pinpointed!
« Reply #17 on: June 20, 2007, 06:08:13 pm »
Hmm... still 20.4 MB having Codeblocks.cbp open with no code completion enabled, and 105.4 with it.  8)

Quote from: rickg22 on June 20, 2007, 05:38:54 pm
So, should I change delete for delete[] in next SVN? er, I read the link. I'll do it tonight.
Yes definitely, the other one is wrong and only works accidentially.


Quote from: rickg22 on June 20, 2007, 05:38:54 pm
Except this function is low level. The Todo plugin, for example, distinguishes between open files and in-disk files.
The todo plugin should not really have to do with anything low level, I think. No component should, unless that's really necessary.
Some of the problems we have come from the fact that every component does its own low-level stuff, with filenames, strings, mangling arraystrings into strings and back, loading files, converting... adding a slash here, converting there, normalizing here but not there, pushing an event handler, tampering here and there, you get the idea.

Ideally, a plugin (or every other component) should be saying "ok, I am being told this is a path, I have no idea how it is encoded or what it corresponds to, now give me the data that belongs to this file, and no, I don't care how you do it".
You should not care whether a pathname is absolute or relative to your project directory or some subdirectory of it, or the root of your partition. The new file wizards *still* don't get this right (I've just had it fail again 5 minutes ago), and ProjectManager doesn't either, if the ScriptManager is involved. Ideally, they should all be saying "hey, I don't care... I have this 'thing' here, now you tell me what it is".
Logged
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5493
Re: HUGE MEMORY LEAK pinpointed!
« Reply #18 on: June 20, 2007, 06:54:00 pm »
I hadn't seen this post but when I looked at the change I saw the leak was not fixed, so the delete [] has already been put there by me. ==> really fixed now ;-)
Logged

Offline Grom

  • Almost regular
  • **
  • Posts: 206
Re: HUGE MEMORY LEAK pinpointed!
« Reply #19 on: June 20, 2007, 08:05:00 pm »
malloc,free works faster then new delete[] :lol:
Logged
gcc+winXP+suse.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: HUGE MEMORY LEAK pinpointed!
« Reply #20 on: June 20, 2007, 08:32:13 pm »
BTW guys; In wxScintilla there are at least two delete's instead of delete[]'s, too. Should we fix that?!

Edit: Don't worry: It's only in my wxScintilla version (1.71.1) the one from SVN seems to be OK though... I should file a bug report to the wxScintilla authors...)
« Last Edit: June 20, 2007, 08:36:46 pm by MortenMacFly »
Logged
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 Grom

  • Almost regular
  • **
  • Posts: 206
Re: HUGE MEMORY LEAK pinpointed!
« Reply #21 on: June 20, 2007, 08:48:56 pm »
If you will continue in the same way - that will be one more studio :lol:.
Logged
gcc+winXP+suse.

Offline rjmyst3

  • Multiple posting newcomer
  • *
  • Posts: 117
    • wxFormBuilder
Re: HUGE MEMORY LEAK pinpointed!
« Reply #22 on: June 20, 2007, 09:53:26 pm »
Quote from: byo on June 20, 2007, 05:08:32 pm
Quote
Also, maybe someone with the required knowledge could run C::B through valgrind or similar?

That would require some knowledge since wxWidgets would have to compiled with valgrind first. It would be much easier to use wxWidget's built-in memory leak search features.I remember that when using wx with Visual Studio, such things was turned on automatically and gave nice reports at the end of execution.

BYO

valgrind does not require a recompile of anything - it is not intrusive. As long as the executable has debugging symbols it will work.
Logged

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: HUGE MEMORY LEAK pinpointed!
« Reply #23 on: June 20, 2007, 10:04:56 pm »
Quote from: rjmyst3 on June 20, 2007, 09:53:26 pm
valgrind does not require a recompile of anything - it is not intrusive. As long as the executable has debugging symbols it will work.

Hmm, that's really nice :) Maybe I've confused it with something else or used very early release in the past so I could swear that it redeclare new/free :oops:.

BYO
Logged

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5493
Re: HUGE MEMORY LEAK pinpointed!
« Reply #24 on: June 20, 2007, 10:17:59 pm »
idea : valgrind plug-in in linux, which allows you to run the debug target.
I have never used it, so maybe the idea is not even possible, dunno. But this would be super cool  ...
Logged

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: HUGE MEMORY LEAK pinpointed!
« Reply #25 on: June 20, 2007, 10:18:24 pm »
Quote from: rjmyst3 on June 20, 2007, 09:53:26 pm
valgrind does not require a recompile of anything - it is not intrusive. As long as the executable has debugging symbols it will work.
Now that we have that topic: Does anyone know something  similar (and free) for Windows?!

Quote from: killerbot on June 20, 2007, 10:17:59 pm
idea : valgrind plug-in in linux, which allows you to run the debug target.
Vote++. ;-)

With regards, Morten.
Logged
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 Der Meister

  • Regular
  • ***
  • Posts: 307
Re: HUGE MEMORY LEAK pinpointed!
« Reply #26 on: June 20, 2007, 10:25:24 pm »
Quote from: byo on June 20, 2007, 05:08:32 pm
Quote
Also, maybe someone with the required knowledge could run C::B through valgrind or similar?

That would require some knowledge since wxWidgets would have to compiled with valgrind first.
No, this should not be necessary. At least it was not as I hunted some memory leaks in Code::Blocks with valgrind more than one year ago.

Quote from: Biplab on June 20, 2007, 05:32:58 pm
Couple of Intel's tools are now free for Non-commercial use on Linux. Can anyone tell us whether Intel VTune Performance Analyser be used to detect Memory Leak or so? :)
No, I can't tell you anything about VTune but I would guess that you have to compile Code::Blocks with the Intel Compiler to use this program. And last time I tried to compile Code::Blocks with icc I had to fix quite a lot of issues to get it compiled. And if I remember correctly I was not able to run it after compilation finished. Don't know why, I had given up at this point and just fixed a few things for which the compiler showed some warnings.

Unfortunately Code::Blocks heavily relies on gcc and because of this it is not really possible to use tools for other compilers like VTune or the DevPartner Profiler which uses the Microsoft Compiler.
Logged
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5493
Re: HUGE MEMORY LEAK pinpointed!
« Reply #27 on: June 20, 2007, 10:27:59 pm »
insider information.
DevPartner/BoundsChecker (Numega/Compuware) should be coming to linux and gcc ...

DevPartner is really good. It helped me spot memory leaks in code from a colleague today very quickly.

EDIT : just read the quick starters guide of valgrind. Some basic stuff should be up and running quickly.

- start the valgrind run command of our 'to-be' plugin
- select the target to (eventually warn if not a debug ('-g') build)
- launch valgrind with the correct arguments (command line arguments can be taken over ??are they exported in the sdk ???)
- capture all the output of valgrind and dump them in a special valgrind message panel [in the future parse and have a valgrind messages list, so double click thakes you to the code line, like with build message list]
« Last Edit: June 20, 2007, 10:35:40 pm by killerbot »
Logged

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: HUGE MEMORY LEAK pinpointed!
« Reply #28 on: June 20, 2007, 10:50:06 pm »
Quote from: killerbot on June 20, 2007, 10:27:59 pm
insider information.
DevPartner/BoundsChecker (Numega/Compuware) should be coming to linux and gcc ...
Where did you get these information?  :shock:

Quote from: killerbot on June 20, 2007, 10:27:59 pm
DevPartner is really good. It helped me spot memory leaks in code from a colleague today very quickly.
Yes it is. Actually, I only used the profiler, but this one is *really* nice. With it's help I got huge speed improvements for my little raytracer. Would probably be nice to run it on Code::Blocks.

Just another comment to valgrind: Running Code::Blocks in valgrind was really easy. If I remember correctly I just used a few command-line options to get more output but then it worked really well and most of the time even provided quite accurate line numbers if it found some problem.
But: Simply starting Code::Blocks in valgrind took ages. Should have been around 5 minutes (!) on my Pentium 4.
Logged
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5493
Re: HUGE MEMORY LEAK pinpointed!
« Reply #29 on: June 20, 2007, 11:28:57 pm »
I got this info from a compuware sales guy. But it is not finished yet, they are working on it.
Logged
Pages: 1 [2] 3 4 5 6 7   Go Up
« previous next »