Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Hit enter a little to fast there. valgrind should be able to find it, if it has one, you might need to use some of the more non-default features of valgrind though. -miah On Thu, Jul 15, 2004 at 04:01:48PM -0400, Samuel Donham wrote: > Hi everyone, > Normally, I wouldn't ask for help with work-related problems, but I'm out > of ideas. If anyone can provide a reasonable answer to this, I'm bringing > a stack of free pizzas to the next BLU meeting. > > One of my clients claims that I have a memory leak in one of our > applications. He claims that 'top' reports my app is slowly consuming > more memory after running for 30 days (now 20 megs, up from 8 when it was > first started). Perhaps there is a memory leak, but I don't think 'top' > is a good indicator of one ('free' would be much better). In addition, > I've searched high and low for the leak with no success. I've also run > Valgrind (http://valgrind.kde.org) on my app, with no report of a leak. > > My question is, does anyone have any creative ideas to prove that a leak > does NOT exist? It's far easier to prove that one does exist than to > prove it does not. Knowing that the memory will likely be released after > some time, I need to prove this but it will take months for the app to run > in order to so. I would like to limit the amount of memory the app is > allowed to consume. I've tried using 'ulimit,' but the app repeatedly > goes over the limit (soft and hard). Using '/etc/security' may work, but > I'm reluctant to try for it's on a per-user basis, and I would like a > per-process basis. > > Any ideas? What's YOUR favorite means of detecting memory leaks? Lastly, > what kind of pizza/soda do you like? > Any help would be greatly appreciated. Thanks guys, see you at the next > meeting. > -sam > > > > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://www.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |