Pointers/memory issues

Hi all,

I'm about to undertake a fairly large research project and I'll be using a cluster of shared linux machines that are rebooted maybe once a year. I do not have superuser privileges on these machines. My previous work in C++ on these machines did not require that I create my own classes or use pointers to them. This time, however, I will have to do that, and while I would like to be able make a flawless program on the first go, I know this is not going to happen, and even if my programs compile without a hitch, I might get careless somewhere and forget to properly destroy allocated resources.

So, given I can never ever reboot these machines and thus obviate any worries about my program hogging up resources even after it's terminated, what would be a worst case scenario in such a situation? Take into consideration that I might run it again and again and again. Also, are there any preventive measures I can take (e.g. run it only inside a debugger?) or any open source tools designed to prevent this kind of mishap?

Run inside a debugger, eg your design studio. When the studio closes, all that memory will be freed usually.
And take care to use some memory management, like shared_ptr with reference counting, to properly destroy your pointers.

Yes, I'm guessing gdb will keep the memory safe. But when I get going and start to run it on my full data set, I'm going to need it to be fully optimized (the g++ -O4 option), and I won't want to run that in a debugger environment.
As for shared_ptr, it's a boost object, and I can't install it since I don't have root privileges. So the alternative would be auto_ptr, but when I investigated it, it seems it's tricky to create arrays of custom classes (since auto_ptr doesn't work with stl containers), so I'm kind of stuck here.

I can lend my own memory manager if such needs be. I made one myself. It kind of imitates a smart shared_ptr.
Even when the app is release-worthy, you will still run it inside the debugger until you deem it has no bugs severe enough to prevent a release.
But even so, when a program exits (or crashes), all its resources are freed, so there's really no worry.

I believe you can download and "install" boost without actually installing anything. You just #include the headers from it.

No offense intended to Elysia's implementation, but I would see if I could use the almost-standardized smart pointer over a home-grown one.

Also, pass by value a lot, since you won't have to worry about memory leaks in that case.

There are programs to help identify memory leaks (Valgrind maybe?) but you might have to install them.

Quote:

---

Originally Posted by Daved

No offense intended to Elysia's implementation, but I would see if I could use the almost-standardized smart pointer over a home-grown one.

---

Yes indeed, I just mentioned it just in case ;)

Daved: Thanks for the pointer (no pun intended) about boost

Elysia: Thanks for offering to share your code.

But my real question (I really am curious): what's the worst thing that can happen if I get careless about memory management and just run my programs on and on and on without rebooting the machine? Will I be killing the machine for my lab mates as well?

I doubt it will go that far, but if you notice memory getting low, try closing your debugger or shutting down your app and restarting it. That will free all the memory they've been hugging.
I tend to run my machine on without reboots (since I use hibernation), and I never encounter such problems. Granted, I have a lot of RAM (3 GB), it worked fine before, even when I had less.

Quote:

---

Originally Posted by cunnus88

what's the worst thing that can happen if I get careless about memory management and just run my programs on and on and on without rebooting the machine? Will I be killing the machine for my lab mates as well?

---

Assuming the OS has proper access checks on your program to make sure it doesn't try to access memory that it shouldn't, and assuming that it properly releases the memory when the program closes, there will be no lasting effects of a memory problems, besides the code not working.

That is to say, a good secure OS should prevent code with regular permissions from overstepping its bounds.

Quote:

---

Originally Posted by King Mir

Assuming the OS has proper access checks on your program to make sure it doesn't try to access memory that it shouldn't, and assuming that it properly releases the memory when the program closes, there will be no lasting effects of a memory problems, besides the code not working.

---

Uh oh, are you saying, that in practice, I can be as careless as I want with memory management?

Quote:

---

Originally Posted by cunnus88

Uh oh, are you saying, that in practice, I can be as careless as I want with memory management?

---

Without fear of harming your computer, yes.

Now getting your program to do what you want it to do is another story.

Certainly, a Linux app that exits will have all it's memory released.

As long as your process doesn't use so much memory that others start to "notice", you can actually ignore freeing your memory entirely - not a good plan for a large amount of memory allocation, or for long-term running server processes, and it's obviously not "good style" to not free memory.

--
Mats

Ick, even a tiny resource leak will crash your program in polynomial time. Im currently debugging an application that is leaking handles. It only leaks a few per second, but thats enough to make it stop functioning after about 15 minutes. With memory, you migth get away with it longer, but eventually it will crash. Inceidentally, it doesnt matter how much physical ram you have, as the program will function right up until it hits the per process limit. The leaked memory, while allocated, will almost certainly be paged. The performance hit comes if the memory is highly fragmented, such that large portions of it cant be paged out due to being in the same page as in-use blocks.

Thanks guys. For the moment, it's enough for me to know that (almost) no matter what I do, I won't be maiming the machine for good. My program is not supposed to be a perpetual process, so I can kill it if things get iffy.

I had a sudden, "Huh? Come to think of it..." moment.

If memory is supposed to be completely freed after a program terminates, no matter how badly written it was, what's with all the memory leaks in Windows programs? I mean, you start windows, look at memory consumption, about 80 megs being used, all nice and fine, then you run a few programs, kill all of them, and you check your memory consumption, and it's hovering around 130 megs. Then what's using that 50 megs (or 100 or whatever) when there are no active programs (other than background services)?

Disk cache, holding the program images in memory in case you want to start them again, and so on. Just because memory is used doesn't mean the OS can't make it available for programs.

Windows likes to hog memory itself for caches and stuff and other things, of course.

On Linux, the only resources your program can "hog" after it terminates are disk space (obviously) and SysV shared memory regions. If you create shm regions and don't destroy them before exiting, those regions will stick around.

EVERYTHING else is always released back to the OS.

You also have the remote possibility of triggering a kernel bug and crashing a box, but given that these machines reboot so rarely, I suspect the kernels are pretty solid.

If you are utterly paranoid, you could run everything inside User Mode Linux.

Quote:

---

Originally Posted by cunnus88

Yes, I'm guessing gdb will keep the memory safe.

---

Programs running under gdb don't execute any differently than normal. Running under the debugger doesn't make anything safer, really. The debugger is just a process which watches and manipulates another process. It doesn't even slow it down.

Quote:

---

As for shared_ptr, it's a boost object, and I can't install it since I don't have root privileges.

---

There's nothing stopping you from using Boost. You don't have to install it in /usr/local...

Anyway. Especially on Linux there's really nothing to fear. Write code!