I find myself in a situation in which I need to exit a cross-platform C++ application immediately, without running destructors, and also without causing a crash. How can I do that?
exit(0) runs the destructors;
quick_exit(0) is not implemented in VC++;
abort() causes a crash;
_Exit(0) does not seem implemented in VC++ (or at least does not appear in MSDN);
the documentation of _exit(0) is unclear as to whether it calls destructors – apparently, it calls them under Windows.
I believe that I can use quick_exit under non-Windows platforms, but I am lacking a solution for VC++.
Clarification (since people ask why I wish to avoid destructors) This is an optimization scenario. I am dealing with a large application that manipulates Gigabytes of RAM, allocated in complex graphs, with several processes, numerous threads, thread-safe reference-counting, watchdogs, etc. The memory management/resource deallocation mechanism is optimized for keeping the application responsive during runtime use and/or monitor possible errors (depending on build flags), but these mechanisms are clearly overkill during shutdown, keeping the CPU very busy for many seconds, draining the battery, etc – long after we are sure that all file descriptors/handles have been closed. This makes users unhappy, so I am experimenting how to improve this, preferably without having to refactor everything.
The call quick_exit was designed specifically for such scenarios, but isn't supported by VC++. So I'm looking for an alternative for that platform.
use C signals as defined in signal.h it should be supported on most platforms.
You specifically should be calling a raise() with a SIGABRT or kill().
Related
I have a problem with long running boost::regex_match(...) invocation in a threaded process environment. But it could be another lib (API call) having the same problem.
Is there a generic way to set up a watchdog for such?
For non-threaded process alarm() can be used to detect timeout.
However, signals don't play nicely with threads. I can avoid direct use of alarm() in the thread and delegate timer mgt. to a dedicated separate thread and let that one use pthread_kill(...) to address the correct threads (this is just an idea - i didn't yet verify that part).
However, also this only interrupts and detects the situation, but cannot gracefully stop boost::regex_match(...).
I played around with Throwing an exception from within a signal handler using sigsetjmp() and siglongjmp() for the thread using boost::regex_match(..).
But it causes memory leaks in boost::regex_match(...) becausesiglongjmp()` bypasses destructors.
How can i gracefully stop a 3rd party API call - presuming that it's implemented exception safe?
Or does it have to be supported by some "stoppable" feature actively implemented in the 3rd party API? (is there some for the boost library?)
Maybe some strange idea, but:
Code can be implemented to be "thread-safe" and/or "exception-safe".
Would it be an option to define "longjmp-safe"? This could be done by passing an additional token to a lib to let is associate all resource allocations to that token. After longjmp() the client SW could ask the API separately to release those resources.
simpler maybe would just be some central init()/release() or register()/unregister() API call, by which the API could clean-up itself.
In a case where you have to:
monitor exceeding execution time
stop execution of processing
you should simply think for tasks instead of threads.
Using threads is something which sounds like "state of the art" but in practice tasks are very often the better way of implementation. Especially for controlling memory leeks in "undefined" end of execution, confine unwanted memory excess and control stack overruns etc.
In the case you have mentioned I tend to implement that as tasks. IPC works well on all known platforms but is not portable. If portability is no problem, changing to a task based solution is not a big deal.
A hanging task can be killed by a os call and all locks, memory and other resources like ipc/shared memory/pipes etc. will be removed automatically. So this fits much better to your problem and it did not depend on your external and maybe unchangeable third party components.
I'm making a desktop programming game with C++11, Qt 5.6 (soon 5.7 once V-Play supports it), and QML. The user will be able to write arbitrary code to solve puzzles; however, the code should be entirely sandboxed and not cause problems with the rest of the application.
So I instantiate a scripting engine whose environment I completely control and run the player's code through that. I won't say what scripting engine because I don't want a solution to rely on the engine (plus, I may support multiple languages). When the player hits "Submit", I run the script asynchronously, so that the rest of the game is still responsive.
But here's my problem: What happens if the player's code takes a long time to run? Or worse, what if it's an infinite loop? The player will be making mistakes as they learn, so "they shouldn't do that" is not a valid answer here.
So I'll just let the player terminate their code at will, fine. But how can I do that without risking undefined behavior, memory leaks, a crash, or other things that may negatively affect the game?
Of relevance is the following:
The solution should be multi-platform.
The solution should not depend on what scripting engine I'm using.
I'm not passing around data between threads, so I don't need to worry about data races.
The QFutures that QtConcurrent::run returns do not support QFuture::cancel.
You cannot rely on being able to safely kill C/C++ threads. Any thread which is doing any meaningful work will need to acquire locks and/or allocate memory to do its work; killing the thread will potentially leave some locks permanently held, or memory never deallocated. Depending on the details, this is likely to cause your application to run out of memory after many scripts are killed, or cause it to lock up entirely if the main thread tries to acquire locks held by a killed interpreter thread.
If you need to be able to interrupt running scripts, you will need to choose scripting engines which specifically allow for this. Not all will; you will need to avoid the ones that don't support it.
I have a C++ Windows program that fails to set the exit code. The program is very complex and I'm currently unable to reproduce this with a simple test case. I do know that the program calls exit(1) because I have a breakpoint on that line. Immediately after I step over it, the debugger (VS2010) prints The program program.exe has exited with code 0 (0x0). When I run it from the shell, %ERRORLEVEL% is also set to 0.
I use subsystem:console and plain old main (no WinMain).
This only happens on Windows Server 2008 R2, not on my Windows 8.1 laptop. I'm running the same executable on both.
I have tried to use exit, _exit, ExitProcess, and return (the offending call is in main), but none of those seem to have any effect. I also have tried to return other codes, also with no result.
There's a similar question but I cannot reproduce the results described in it. My program does use threads.
How can I approach debugging this issue? I'm rather baffled.
I have tried to use exit, _exit, ExitProcess, and return
You've eliminated all reasonable explanations, particularly with ExitProcess(). There is only one possibility left, you need to try TerminateProcess(). If that still doesn't set the exit code then you need to shove that machine out of a 4th story window.
But with the expectation that it now works. The difference between ExitProcess() and TerminateProcess() is that the former ensures that all DLLs are notified by the termination. Their DllMain() function gets called with fdwReason = DLL_PROCESS_DETACH. Which gives a DLL the opportunity to do something icky like calling Exit/TerminateProcess() itself, thus screwing up the exit code.
Finding such a DLL can be difficult if you don't have all the source code. Could be an injected one as well, there are entirely too many around these days. Best thing to do is to set a breakpoint on system call so you can catch it in the act, you probably want to do this regardless.
Once you step into main(), use Debug > New Breakpoint > Break at Function and enter {,,ntdll.dll}_NtTerminateProcess#8. Press F5 and the debugger now stops just before the program terminates. Look at the Call Stack to find the evil-doer.
Strange symptoms involving exit(), _exit(), ExitProcess(), and others in a multithreaded program - particularly if the symptoms vary between hosts - have a smell of a variable being modified or accessed by different threads, without synchronisation.
Looking at the other thread you linked to, it appears you are using a volatile variable to communicate between threads, but not using any form of synchronisation (for example, code which accesses the value of that variable and code that modifies that value need to cooperate via means of a critical section, mutex, or comparable construct).
That little bit of indirect evidence makes the smell even stronger.
The basic problem I suspect is that declaring a variable as volatile is neither necessary nor sufficient to ensure that variable always has values that will make sense to your program. In particular, it is not sufficient to prevent a thread which is modifying a variable from being preempted when the modification is only partly complete, and for another thread to attempt accessing or modifying the affected variable.
If you look up some articles by Herb Sutter (particularly those concerned with thread synchronisation in his "Guru of the Week" series) you will find detailed explanations of why that is so. Other authors also describe such things, but Sutter's articles are ones that I recall offhand.
The solution is to introduce some means of synchronisation, and for EVERY thread in your program to religiously use it before accessing or modifying variables shared between them. This avoids the various problems (race conditions, operations being preempted partway through) that would cause symptoms like you describe.
Such problems are rarely caught by stepping through with a debugger. The reason for that is that the symptoms are an emergent property. Several unlikely and often independent occurrences, in disparate threads of execution, must occur together. Debuggers do typically change the timing of events in programs, and timing is a critical consideration in the symptoms emerging.
Options include making key variables atomic (so particular operations cannot be preempted), critical sections (where the threads explicitly cooperate within a program), or mutexes (which, depending on definition, allows threads in different programs to explicitly cooperate before accessing shared memory).
Yes, this introduces a bottleneck in your program - a point where every thread must rendezvous and potentially wait for each other. That can affect throughput of your program. Some people advocate using volatile variables to avoid such concerns. More often than not, the result is intermittent symptoms in long running programs like you have described in this question and the "similar question" you linked to.
It doesn't matter whether you use standard means of synchronisation (e.g. introduced in C++11) or windows specific means (WIN API functions). The important thing is that you use a deliberate synchronisation method, rather than just making variables volatile. Different options for synchronisation have different trade-offs, so you will need to make a decision relevant to needs of your program.
Another consideration is to signal all threads so they close cleanly, wait until they are all closed, capture their exit codes, and THEN exit the program. It is often less error prone to do this in the thread running main() - which ultimately starts the process, so is more likely to have access to information it needs to cleanup correctly. If another thread decides the program needs to exit, then better if it communicates that need back to main() to do it.
I'm creating a concurrent memory reclamation algorithm in C++. Periodically, the stacks of executing mutator threads need to be inspected, so that I can see what references the threads are currently holding. In the process of doing this, I need to also check the registers of the mutator thread to check any references that might be in there.
Clearly many JVM's and C# vm's have no problem doing this as part of their garbage collection cycles. However, I haven't been able to find a definitive solution to this issue.
I can't quite tease apart what is going on in the Bohem garbage collector in order to inspect the root set, if you can (or know how its done), I'd really like to know.
Ideally I would be able to cause the mutator thread to be interrupted, and execute a piece of handler code which would report it's PC and also flush any register-based references into the stack, and then perhaps help finish the collection cycle. I believe that most compilers in most systems will automatically flush the registers when interrupt or signal handlers are called, but I'm not clear on the specifics, or how to access that data. It seems that separate stacks might be used for interrupt and signal handlers. Additionally, I can't find any information about how to target a particular thread, or how to send a signal. Windows does not seem to support this form of signaling anyway, and I would like my system to run on both Linux and Windows on x86-64 processors.
Edit: SuspendThread() is used in some situations, although safepoints seem to be preferred. Any ideas on why? Is there any way to deal with long-lasting I/O waits or other waits for kernel code to return?
I thought this was a very interesting question, so I dug into it a bit. It turns out that the Hotspot JVM uses a mechanism called "safepoints" which cause the threads of the JVM to cooperatively all stop themselves so that the GC can begin. In other words, the thread initiating GC doesn't forcibly stop the other threads, the other threads voluntarily suspend themselves by various clever mechanisms.
I don't believe the JVM scans registers, because a safepoint is defined such that all roots are known (I presume this means in memory).
For more information see:
HotSpot Glossary -- which defines safepoints
safepoint.cpp -- the source in HotSpot that implements safepoints
A slide deck that describes safepoints in some detail (look 10 slides or so in)
In regards to your desire to "interrupt" all threads, according to the slide deck I referenced above, thread suspension is "unreliable on Solaris and Linux, e.g., spurious signals." I'm not sure what mechanism even exists for thread suspension that the slides would be referring to.
On windows you should be able to get this done use SuspendThread (and ResumeThread) along with GetThreadContext (as Hans mentioned). All of these functions take handles to the specific thread you intend to target.
To get a list of all threads in the current process, see this(toolhlp32 works on x64, despite its bad naming scheme...).
As a point of interest, one way to flush registers to the stack on x86 is to use the PUSHAD assembly instruction.
I have employed MFC Synchronization objects in my projects without any issues. But recently I came across an article, which explains MFC synchronization is completely wrong. I'm not sure which version of MFC he's talking about but I seriously believe that MFC has matured in the recent versions. I'm using MFC library which comes along with Visual Studio 2008 Installation. Is it safe to use MFC libraries of this version especially for synchronization?
On mutex timeouts, there is a school of design for concurrent software that says you should not use timeouts for normal operation. Your design would then involve mutexes or other locks that do not time out ever, and timeout is effectively a mechanism for dealing with deadlocks: you try to design your system not to exhibit deadlocks, but in case they do happen, you would rather have it fail more or less gracefully, than stay dealocked forever.
If you use your locks in this way, it may well not matter much why trying to acquire a mutex failed.
On the other hand it does seem maybe not fundamentally broken, but at least somewhat deficient that this information is lost for no good reason and there are better frameworks out there that provide OO wrappers for mutexes, so regardless of this avoiding MFC in this case seems like a good idea.
The author's assertions are not appropriate for every condition, but for specific set of conditions. Lock returns BOOL, and you mostly would not care if it failed because of some reason. Most of the time you would call to get the lock or wait. In other cases, FALSE would mean failure. And if you need to check timeout, you can use native API (which is rare).
Recursive CSingleLock is absurd. You don't use same object to relock. You can safely use multipe CSinlgeLock objects to gain recursive access.
CEvent, CMutex and other named-object classes can be used accross process. I have used it!
I don't use Semaphores. May be some other can comment.