Memory Leak in Dev-C++ on Windows 2000

[Nobody/Anonymous]

Hello all,

I reported this bug to the Dev-C++ development team, 10 days ago; however, I have been largely ignored.  Could someone please see if they can reproduce the issues I am talking about below.  My original correspondence (names and email addresses omitted) are below.  Note:  you'll want to start with the original email, at the bottom of this post.

Thanks

#############################################
************* MY SECOND EMAIL **********************
#############################################

Hi,

Assuming this to be the case, this is still a serious problem.  Try the following and you'll get a better appreciation for the problem:

1. Take that zebedee.c file and double (387 KB) or tripple (580 KB) it's size by copying its original content to the end of the file.
2. Now launch Dev-C++ and open one of the new files.
3. Note that for double the file size, devcpp.exe memory usage grows to 65 MB (for the doubled file) or 87 MB (for the trippled file).

I don't think it's beyond reason for someone to open workspaces or files larger than those above; therefore, I would rate this issue as critial - even if it's an issue with the development tool Dev-C++ is programmed with.

Dev-C++ is therefore very heavily memory bound, in it's current state, and cannot handle much more than small development tasks.

Hope that shines more light on the issue.

Thanks,

Windows 2000 SP3, IE6.0 SP1
512 MB RAM

#############################################
************* REPLY FROM A DEV-C++ DEVELOPER
#############################################
>From: "a Dev-C++ developer"
>
>I think this is just Delphi's weird, weird memory manager and VCL...
>
>

#############################################
************* MY ORIGINAL EMAIL **********************
#############################################
>
> > Hi,
> >
> > Wasn't sure which of you to direct this to, but here goes:
> >
> > There's a bad memory leak in the recently released Dev-C++ 4.9.7.0 (using
> > Minwg/GCC 3.2 release), involving Dev-C++'s handling of files.
> >
> > The specific file for which I noticed the leak is the source file for
> > Zebedee 2.4.1, which you can download from here:
> > http://prdownloads.sourceforge.net/zebedee/zebedee-2.4.1.tar.gz?download
> >
> > Once you've downloaded the file, extract the file zebedee.c (file size is
> > 185 KB) and follow these steps:
> >
> > 1. If Dev-C++ is alrealy open, close.
> > 2. Launch Windows Task Manager.
> > 3. Start Dev-C++
> > 3. Note that Windows Task Manager indicates that Dev-C++ is using just over
> > 5 MB at this stage.
> > 4. Open zebedee.c with Dev-C++, using the File --> "Open Project or File..."
> > menu option.
> > 5. If the memory leak has shown itself immediately, you should see that, at
> > theis point, the devcpp.exe process int Windows Task Manager is consuming
> > between 35 MB and 44 MB of RAM.
> > 6. Choose File --> Close to close the file zebedee.c, but do not close
> > Dev-C++.
> > 7. If you did not observer the large memory spike in Step 5, skip to Step
> > 10.
> > 8. Note that the devcpp.exe process is still at around 42 MB or so.
> > 9. Skip to Step 11
> > 10. Open then close a different file with Dev-C++, then go to Step 4.
> > 11. Choose Tools --> Editor Options
> > 12. Without making any changes, click "Okay"
> > 13. Observe now that Windows Task Manager indicates that Dev-C++ is
> > consuming either about 9.9 MB or 632 KB.
> > 14. End of test
> >
> > Test System:
> > Windows 2000 SP3, IE6.0 SP1
> > 512 MB RAM

[Nobody/Anonymous]

mind posting the .c file in error... the link you gave doesn't seemt to have one...

Zero Valintine

[Nobody/Anonymous]

I just tried the link and it works.  You have to extract the zebedee.c file from the archive at the link.  If that link still does not work for you, try: http://www.winton.org.uk/zebedee/zebedee-2.4.1.tar.gz

I want to avoid getting into copyright issues with the author; therefore, I will not post the source file here.

Thanks

[Yiannis Mandravellos]

Hi Idon,

What you 're describing here is *not* a memory leak. A leak happens when the program does not release allocated memory blocks after use. And when this happens, only the OS(?) will free it up upon your program's shutdown.
As you have already noticed, when you go to Editor Options and click OK, the "leak" goes away (I 'll explain why). That's why it's not a leak. We know *exactly* where this memory is allocated to and what it is used for.

Before I go any further let me give you my results following the procedure in your first mail...

1. Fire-up devcpp (v4.9.7.1 - yes I know, it's not released yet ;): MemUsage=12.116K
2. Open zebedee.c: MemUsage=14.828K
3a. If I do File/Close: MemUsage=14.364K
3b. If I do File/CloseAll: MemUsage=12.572K

Everything has to do with code-completion.
Now, let me explain this behaviour.

First of all notice that on devcpp startup it consumes just over 12M while you mentioned 5M. Why is that? Because, on my machine, I use a code-completion cache[1] file which is loaded at startup.
After you open the file in question, everything is as it should be[2]. The mem usage goes up a bit because it scanned and kept the tokens of the opened file.
The question is why do we get different results when using FileClose or FileCloseAll? Because in the case of FileClose, the tokens are not deleted from memory. Think of it as caching. There is the possibility that you might re-open the file to edit it. Why go all over again? On the other hand, if you use FileCloseAll, Dev considers it as "Hey, I'm done working here" so it frees up everything having to do with the open files (regarding code-completion).

One last thing: if you keep opening and closing the file repeatedly, you 'll find that the mem usage increases a little bit every time. This is due to some housekeeping code and data. Complete memory free-up will happen when you exit Dev or click OK in Editor Options. What do Editor Options got to do with the mem usage, I hear you saying. In there, exist the configuration of code-completion. When you exit Editor Options (with OK), the parser re-initializes freeing-up any memory already used (the same goes for the Dev shutdown case).

I hope this enlightens you on the internals of Dev. If you think that this is not the correct behaviour, that's another topic. But leak? No...

Cheers,
Yiannis :)

[1]: The code-completion cache file is a cache of pre-parsed files that is loaded at startup and don't need to be parsed evey time they are needed. So, if you add the file windows.h in the cache, the core WinAPI will be parsed once and saved to be available for code-completion every time you open Dev without the need to be re-parsed. Major time-saver.
[2]: That depends on the settings for class-browsing and code-completion. If you 've enabled the code-completion cache, if you allow local and/or global header files scanning etc.

[Nobody/Anonymous]

Yiannis,

Thanks for you reply and explanation; however, the fact that you tested with 4.9.7.1 fails to invalidates my results, with regard to the magnitude of memory chewed up by 4.9.7.0.

Nonetheless, your tests appear to suggest that 4.9.7.1 may have better memory performance.

I will restest the memory usage with 4.9.7.1 once released.