Hello everyone,
I have a question about resource cleanup using Vulkan.
I was working through a setup-tutorial for Vulkan and came across this passage:
The tutorial in question is API without Secrets.
Here he explicitly says that the OS and driver cleans up everything our application leaves behind. Is it actually true that the application could crash _after_ we exited and cause trouble?
I heard at least from Casey Muratori on Handmade Hero and, I think, from Jonathon Blow on some stream that it is really normally never necessary to free resources we used when we quit the application (because the OS has to do it anyway) and that unnecessary cleanup is one reason many programms actually take so much time closing.
Thanks in advance!
T.J.
I have a question about resource cleanup using Vulkan.
I was working through a setup-tutorial for Vulkan and came across this passage:
After the application is closed, the OS should release memory and all other resources associated with it. This should include Vulkan; the driver usually cleans up unreferenced resources. Unfortunately, this cleaning may not be performed in a proper order, which might lead to application crash during the closing process. It is always good practice to do the cleaning ourselves.
The tutorial in question is API without Secrets.
Here he explicitly says that the OS and driver cleans up everything our application leaves behind. Is it actually true that the application could crash _after_ we exited and cause trouble?
I heard at least from Casey Muratori on Handmade Hero and, I think, from Jonathon Blow on some stream that it is really normally never necessary to free resources we used when we quit the application (because the OS has to do it anyway) and that unnecessary cleanup is one reason many programms actually take so much time closing.
Thanks in advance!
T.J.
Edited by Tim Dierks
on
Reason: Initial post
Yes, the OS should be able to clean up everything on closing, I don't know how much it has access to a peripheral's resources to clean them up without the help of their driver.
Personally, I had one case where one of my apps crashed when closing because of a lack on cleanup: D3D12 doesn't like the application to close when its window is in borderless-fullscreen mode, I have to switch it to windowed before closing.
There's also the SoLoud library that requires calling explicitly a cleanup function to avoid some thread randomly crashing the app when closing.
Vulkan drivers are relatively recent, I don't know what the spec says about cleanup, but if it states closing the application is enough, maybe in a few years it will actually always be true?
Personally, I had one case where one of my apps crashed when closing because of a lack on cleanup: D3D12 doesn't like the application to close when its window is in borderless-fullscreen mode, I have to switch it to windowed before closing.
There's also the SoLoud library that requires calling explicitly a cleanup function to avoid some thread randomly crashing the app when closing.
Vulkan drivers are relatively recent, I don't know what the spec says about cleanup, but if it states closing the application is enough, maybe in a few years it will actually always be true?
Edited by Guntha
on
Wouldn't try it with Vulkan because practice often differs a lot from theory
Official OpenGL drivers from leading hardware vendors crashed from memory leaks even when everything was cleaned up properly (creating and destroying 1000 OpenGL contexts for example is technically correct but strange and unexpected), so expect things to go very wrong in the future if not following best practices for resource allocation. All it takes is one bad implementation from someone who just tested the drivers using Unity and Unreal, or left driver cleanup as one of many forgotten todos that never takes priority over optimizing for the next AAA games.
Don't forget that libraries may do other things
Even if local resources are freed by the system, a game's network library might list active players on a server somewhere else. Background threads for loading world geometry may still be running and cause undefined behavior if libraries aren't terminated.
Once you have a growing memory leak that might actually crash
you better not have 1000 false detections from not cleaning up resources. This goes for both heap memory and API resources with their own debuggers. It's a lot easier to track down a dangerous memory leak if you can comment out different parts of the program until the leak goes away. Ideally show a leak warning on termination even without running a debugger so that you know exactly when the leak was introduced and go directly to the last edited line.
Official OpenGL drivers from leading hardware vendors crashed from memory leaks even when everything was cleaned up properly (creating and destroying 1000 OpenGL contexts for example is technically correct but strange and unexpected), so expect things to go very wrong in the future if not following best practices for resource allocation. All it takes is one bad implementation from someone who just tested the drivers using Unity and Unreal, or left driver cleanup as one of many forgotten todos that never takes priority over optimizing for the next AAA games.
Don't forget that libraries may do other things
Even if local resources are freed by the system, a game's network library might list active players on a server somewhere else. Background threads for loading world geometry may still be running and cause undefined behavior if libraries aren't terminated.
Once you have a growing memory leak that might actually crash
you better not have 1000 false detections from not cleaning up resources. This goes for both heap memory and API resources with their own debuggers. It's a lot easier to track down a dangerous memory leak if you can comment out different parts of the program until the leak goes away. Ideally show a leak warning on termination even without running a debugger so that you know exactly when the leak was introduced and go directly to the last edited line.
Any modern OS will do the resource cleanup for you, otherwise it could not function normally. This includes most of OS'es you know that has virtual memory and user process isolation - so Windows, Linux, BSD, macOS, Android, iOS.
If OS does not clean something up that means it is a bug in OS, not in your code. If there could be bug in OS'es cleanup code then who's not to say that there isn't a bug also in normal path of process exit? Once you accept that, there's no reason not to rely on automatic cleanup - you could stumble un OS bug either way.
In my personal experience I have not seen OS fail to clean up resources from something like Windows XP early days (even then it was super rare, so more like Windows 95/98 days). So I'd say you can rely on it on any modern OS.
If OS does not clean something up that means it is a bug in OS, not in your code. If there could be bug in OS'es cleanup code then who's not to say that there isn't a bug also in normal path of process exit? Once you accept that, there's no reason not to rely on automatic cleanup - you could stumble un OS bug either way.
In my personal experience I have not seen OS fail to clean up resources from something like Windows XP early days (even then it was super rare, so more like Windows 95/98 days). So I'd say you can rely on it on any modern OS.
Edited by Mārtiņš Možeiko
on
Thanks for your answers.
That clears things up and affirms that I had the right idea about resource cleanup. But as Guntha says, you cannot always be sure about such things, as programming is oftentimes not perfect and therefore buggy and things that should work - may not.
Good to keep that in mind I think, especially when one does more obscure stuff that may not have been tested that thoroughly through the use from many people.
In my specific case I think it should therefore be fine to omitt the cleanup, as I am only doing very basic things with vulkan.
That clears things up and affirms that I had the right idea about resource cleanup. But as Guntha says, you cannot always be sure about such things, as programming is oftentimes not perfect and therefore buggy and things that should work - may not.
Good to keep that in mind I think, especially when one does more obscure stuff that may not have been tested that thoroughly through the use from many people.
In my specific case I think it should therefore be fine to omitt the cleanup, as I am only doing very basic things with vulkan.
mmozeiko
In my personal experience I have not seen OS fail to clean up resources from something like Windows XP early days (even then it was super rare, so more like Windows 95/98 days). So I'd say you can rely on it on any modern OS.
I've seen external drivers fail to handle a process crash (aka a process not releasing resources) gracefully. However that was a printer driver where the process crashed (actually I terminated it) while printing and it hung the driver.
Games are more known to crash so I expect graphics drivers to be more crash-aware and handle resource cleanup gracefully even when they aren't cleaned up properly.
I just want to make sure there's no misunderstanding:
If your app crashes while closing, there's probably a bug or bad usage of an API in your code.
After your application has closed (whether it crashed or not while closing), as Martins said, the OS should have been able to release any resource used by the app. Personally I've never seen an app "causing trouble" AFTER being closed.
My previous post was about avoiding the crash that happens while closing the app.
It's usually good practice to "clean up" parts of your app that heavily use multithreading to avoid inter-dependent resources being released in a random order, randomly causing a crash. The worst part is that you may never encounter that crash yourself because threads luckily get destroyed in the right order on your machine. Since the article you linked is from Intel, I guess they know what they're talking about.
If your app crashes while closing, there's probably a bug or bad usage of an API in your code.
After your application has closed (whether it crashed or not while closing), as Martins said, the OS should have been able to release any resource used by the app. Personally I've never seen an app "causing trouble" AFTER being closed.
My previous post was about avoiding the crash that happens while closing the app.
It's usually good practice to "clean up" parts of your app that heavily use multithreading to avoid inter-dependent resources being released in a random order, randomly causing a crash. The worst part is that you may never encounter that crash yourself because threads luckily get destroyed in the right order on your machine. Since the article you linked is from Intel, I guess they know what they're talking about.
Edited by Guntha
on