I have a memory leak in a legacy application that I would like to get rid of (that is, I want to get rid of the memory leak, not the legacy application
I have “de-leaked” the application as good as I know how, and I can find no leaks in the code. So I started looking elsewhere for the error.
We have set up /tmp as a link to /dev/shmem. The application writes and deletes files on /tmp. One of the guys I work with noticed that the memory leak all but disappeared if we turned off this deleting/writing or if we wrote/deleted to something other than /tmp. We can’t turn this file writing in the finished system, so we have to have that, but from this hint I guessed that there’s something funky about the /dev/shmem filesystem and how our application interacts with it.
I had /tmp point to a ramdisk made with devb-ram, and this also made the leak go away.
Has anyone had similar “mysterious” issues with /dev/shmem and memory leakages related to writing/deleting files?
devb-ram would be a good solution, except that it partitions the memory in a way that leaves us with too little memory for the app and too little “disk” space.
devb-ram can easily be configured regarding its size. Be careful also regarding ‘cache’, as it is a devb device, a certain (big) amount of cache may be allocated automatically. This can be reduced by using the blk cache= option.
@Thunderblade: Thank you for your reply. I am aware that I can set the disk size dynamically, but I hit a limit at ~16 MB, much like what is reported here: community.qnx.com/sf/discussion/ … _pagenum=3. I am assuming that these hardware limitations apply in my case as well.
@mario Thank you for your reply. Do you know that a problem like the one I described existed in 6.3.0 and that it has been fixed? If so, do you know roughly in which QNX release this was fixed? I would like to check out the release notes and see if the changes are likely to solve my problem. Switching to the latest QNX version is not a trivial operation for us, and we’d need to know that it would be worth it.
I have no idea if this is really a bug or not. However Ive been thinking that if for some reason some files are deleted but there is still valid open file descriptor you will not see the file, but its still there. That being said it would also affect HD space, but then you would not see memory leak you`d see HD leak
By the way, is it the program itself that is leaking memory or the whole system.
