Real-World Dangers of C Memory Leaks?

Question

I am learning C, and am concerned about memory leaks. I understand that rebooting will generally flush memory, and assuming I don't run the program again, I will be fine. I am considering using a second, high-power machine. How badly can I screw up my system if:

I do something ridiculously stupid
I use GCC (not sure if the compiler can do anything?)
I have a memory leak and restart
Out of curiosity, if I used a VM. I probably won't, because I simply prefer using real hardware.

Would any of the following things have long-term effects on my system? Thanks.

Hopefully I wouldn't make such a mistake if I were writing enterprise software :) — , Apr 20 '17 at 22:07
You would be very surprised.. https://en.wikipedia.org/wiki/History_of_software_engineering#1965_to_1985:_The_software_crisis — Eugene Sh., Apr 20 '17 at 22:09
Good luck when trying to reboot software for a nuclear power station! — Ed Heal, Apr 20 '17 at 22:09
BSoD from Memory Leak: http://board.pathea.net/index.php?topic=6338.0 — , Apr 20 '17 at 22:11
My question with VMs is about what a memory leak would affect: would the VM get a BSoD or would my main computer? — , Apr 20 '17 at 22:13
If the VM is written properly, nothing happening on it should affect the host. — Eugene Sh., Apr 20 '17 at 22:13
@melpomene I used to run WIndows XP with page file disabled (everything was soooo much faster due to not sitting there swapping all the time) ... only down-side was that when memory got low you found out which programs did not fail gracefully under allocation failure, turns out this includes core OS components, sometimes it resulted in BSODs — M.M, Apr 20 '17 at 22:20

score 4 · Accepted Answer · answered Apr 20 '17 at 22:20

If your product is pure software, the biggest thing that you have to worry about is a memory leak building up and eventually causing the machine to run out of memory, fail to allocate any more, and the application will crash. A lot of memory won't be happening repeatedly and won't even get this far. They will then go away when the application exits. Your application could also potentially corrupt data if something is being modified when it crashes, but that could apply to any type of crash.

If your product controls hardware in some way, you need to be very careful. If the software fails, then you don't know what the hardware may do. As one of the comments said, a spaceship with a memory leak that causes it to crash can make the spaceship crash. Robots could move unexpectedly and cause damage to property or injury to people. Other devices could cause electrical discharges.

As far as handling memory leaks, you just have to be careful. In C, any call to malloc and similar functions needs to be paired with a call to free on all paths of execution. If some type of error occurs, free still needs to be called if the application is going to continue running. Likewise, fopen should be paired with fclose. Here, you can also run into issues with running out of file handles, which is a different but similar problem in many ways. In C++, manual memory allocation with new should be paired with delete, although using "smart" pointers like std::unique_ptr, std::shared_ptr, and std::weak_ptr can ease memory management and prevent memory leaks. Other libraries also provide pointer types that use reference counting to handle their own lifecycle. I would recommend using these any time you can over raw pointers. If you have the option to use C++ instead of C, I would also recommend that. In most cases (performance or otherwise), you don't really need C over C++. If you're not sure that you need C, you can probably use C++.

If you're interested in finding memory leaks, check out valgrind. It has a lot of functionality that will help you find memory leaks and determine their severity.

You can write code without dynamic memory allocation. This code will not have memory leaks. Such regime is used in safety critical systems — Ed Heal, Apr 20 '17 at 22:25
@EdHeal also has a very good point. Avoiding dynamic memory allocation is a surefire way to avoid memory leaks. It will also stop you from having runtime errors due to dynamic memory allocation. For someone that was used to seeing people use raw pointers everywhere in C and C++, there are surprisingly many places that dynamic memory allocation can be avoided. — Daniel Underwood, Apr 20 '17 at 22:30

score 2 · Answer 2 · answered Apr 20 '17 at 22:24

Memory leaks won't damage your machine. When a program terminates, all of its transient resources are released, including whatever memory was allocated to it.

What will suffer is your programming style. Correctly freeing resources is not difficult, but it takes some practice. After a while, you will need to think much less in order to do it. And that is one of the things that makes you a good programmer.

Why does it matter? Because sooner or later, you will start writing programs that run for a long time, perhaps an information server, or a web browser, or a graphic editor. Something that stays active until the user no longer needs it, or because it crashes after using up all available memory. And you don't want to be responsible for the second outcome.

So right now, when you're starting, is the time to develop some good habits. Learn how to do it right, and you won't have to relearn it later.

score 1 · Answer 3 · answered Apr 20 '17 at 22:17

1

According to the answers in the comments:

Memory leaks should go away if the system restarts
~~Spaceships are hard to reboot~~
VMs are safe if they are written properly

Thanks for the quick answers!

answered Apr 20 '17 at 22:17

Real-World Dangers of C Memory Leaks?

3 Answers3