When a program with some theards, mutexes, shared data, file handles crash because of too much memory allocation, which all resources are freed. How do you recover?
If you mean, how do you go back and free up the resources that were allocated by the now-crashed process, well, you don't have to.
When the process exit(2)'s or dies by a signal all of the OS-allocated resources will be retrieved. This is the kernel's job.
You recover by checking the results of resource acquisition functions and not allowing unchecked errors to occur in the first place.
All resources that belongs to the process are cleaned up.
The only exceptions would be the sysv shared memory/message queues/semaphores - which although might have been created by the process are not owned by it.
Related
Linux sem_destroy() documentation says:
An unnamed semaphore should be destroyed with sem_destroy() before the memory in which it is
located is deallocated. Failure to do this can result in resource leaks on some implementations.
But the best I can do is register sem_destroy() to atexit(), which won't be called on aborts or SIGKILL. I have a process responsible for creating and destroying a semaphore on shared memory (a mmaped file), how can I avoid a resource leak on abnormal termination conditions?
On Linux, if the mmaped file is deleted before sem_destroy() is called, is any kind of resource leaked? What resource?
The glibc implementation of sem_destroy does nothing, and this will not change. If you use glibc, you do not have to do anything for freeing up resources. Furthermore, the kernel would free such resources on process termination anyway.
The glibc implementation of semaphores is based on futexes, which is why it does not need any additional resources besides the memory used to store the semaphore.
Is there an operating system-specific way in Linux/Darwin/Windows, to restrict access to certain virtual memory pages to only one thread, so that when another thread tries to access it, the OS would intercept and report an error?
I'm trying to emulate the behavior of fork with multiple processes, where each process has its own memory except for some shared memory, mainly to avoid all programming errors where one worker would access memory belonging to another worker.
As a general proposition, this is not possible. The whole idea of threads is to have multiple streams of execution that share the same address. If you're a kernel mode kommando, you might be able to some up with some modification of the page tables that a thread uses to make pages inaccessible from usermode then unlocks them.
Like in process management and memory management.
Are the scheduler and memory manager implemented as kernel threads that are run on the cpu the moment they are needed? If not, how does the kernel treat them?
Are they like processes, tasks, or some line of code that gets executed when needed?
Some are, some aren't. The terms "process management" and "memory management" are kind of broad and cover a fair bit of kernel code.
For memory management, a call to mmap() will just require changing some data structures and can be done by the current thread, but if pages are swapped out it will be done by kswapd, which is a kernel thread.
You might consider the scheduler a special case: since the scheduler is responsible for scheduling all threads, it itself is not a thread and does not execute on any thread (otherwise it would need to schedule itself... but how would it schedule itself, if it had to schedule itself first in order to do that?). You might think of the scheduler as running directly on each processor core when necessary.
I am reading CUDA By Example and I found that when they introduced events, they called cudaEventDestroy for each event they created.
However I noticed that some later examples neglected this cleanup function. Are there any undesirable side-effects of forgetting to destroy created events and streams (i.e. like a memory leak when you forget to free allocated memory)?
Any resources the app is still holding at the time it exits will be automatically free'ed by the OS / drivers. So, if the app creates only a limited number of events, it is not strictly necessary to free them manually. Still, letting the app exit without freeing all resources on purpose is bad practice because it becomes hard to distinguish between genuine leaks and "on purpose" leaks.
You have identified bugs in the book's sample code.
CUDA events are lightweight, but a resource leak is a resource leak. Over time, if you leak enough of them, you won't be able to create them anymore.
From this answer: When is a C++ terminate handler the Right Thing(TM)?
It would be nice to have a list of resources that 'are' and 'are not' automatically cleaned up by the OS when an application quits. In your answer it would be nice if you can specify the OS/resource and preferably a link to some documentaiton (if appropriate).
The obvious one:
Memory: Yes automatically cleaned up.
Question. Are there any exceptions?
There are some obscure resources that Windows does not clean up when an app crashes or exits without explicitly releasing them, mostly because the OS doesn't know if they're important to leave around or not.
Temporary files -- as others have mentioned.
Globally registered WNDCLASSes ("No window classes registered by a DLL are unregistered when the DLL is unloaded. A DLL must explicitly unregister its classes when it is unloaded." MSDN) If your global window class also has a class DC, then that DC will leak as well.
Global ATOMs (a relatively limited resource).
Window message IDs created with RegisterWindowMessage. These are designed to leak, since there's no UnregisterWindowMessage.
Semaphores and Events aren't technically leaked, but when the owning application goes away without signalling them, then other processes can hang. This is not true for a Mutex. If the owning application goes away, other processes waiting on that Mutex are released.
There may be some residual weirdness on Windows XP and earlier if you don't unregister a hot key before exiting. Other applications may be unable to register the same hot key.
On Windows XP and earlier, it's not uncommon to have a zombie console window live on after a process crashes. (Specifically, a GUI application that also creates a console window.) It shows up on the task bar. All you can do is minimize, restore, or move the window.
Buggy drivers can be aggravated by apps that don't explicitly release resources when they exit. Non-paged pool leaks are fairly common.
Data copied to the clipboard. I guess that doesn't really count because it's owned by the OS at that point, not the application that put it there.
Globally installed hooks aren't unloaded when the installing process crashes before removing the hook.
Temporary files is a good example of something that will not be cleaned up - the handle is released but the file isn't deleted
In Windows, just about anything you can get handle to should be in fact be managed by the OS - that's why you only get a handle. This includes, but is not limited tom
the following (list copied from MSDN docs for CloseHandle() API):
Communications device
Console input
Console screen buffer
Event
File
File mapping
Job
Mailslot
Mutex
Named pipe
Process
Semaphore
Socket
Thread
Token
All of these should be recovered by the OS when an application closes, though possibly not immediately, depending on their use by other processes.
Other operating systems work in the same way. It's hard to an imagine an OS worth its name (I exclude embedded systems etc.) where this is not the case - resource management is the #1 raison d'etre for an operating system.
Any exception is a bug - applications can and do crash and do contain leaks. An OS needs to be reliable and not exhaust resources even in the face of poorly written applications. This also applies to non-OS resources. Services that hand out resources to processes need to free those resources when the process exits. If they don't it is a bug that needs to be fixed.
If you're looking for program artifacts which can persist beyond process exit, on Windows you have at least:
Registry keys that are created
without REG_OPTION_VOLATILE
Files created without FILE_FLAG_DELETE_ON_CLOSE
Event log entries
Paper that was used for print jobs