I am developing a plug-in that runs in several host applications, and which maintains its own threads using the boost::thread library, version 1.53.0.
When running my plug-in in a particular application on Mac, I get a null access error when calling boost::condition_variable::timed_wait(). At the top of the call stack is a call to pthread_getspecific(), which is called from inside the boost thread library.
If I replace timed_wait() with a call to boost::this_thread_sleep(), same behaviour: exception is thrown when pthread_getspecific() is called internally.
This application is the only one which exhibits this kind of behaviour; if I run my plug-in in other hosts, it works as expected.
I don't have much experience with pthreads, but I think the exception must be caused by some properties being set up by the host application. Does anyone have any better idea of what might be going on here?
Thanks!
It turns out that the pthread API calls where not thread safe in my application, causing null pointer crashes whenever I called them in a separate thread.
Related
A while back I made a post regarding creating a dll, for the purpose of injection, that will cause the host application to trigger an Nvidia Optimus laptop to "awaken" the dGpu. This being necessary because of the pathetic system nvidia created here which results in MANY applications not recognizing the presence of the power dGpu, and instead using the integrated intel gpu. (Specifically some video processing apps which take hours longer using Intel's than it would Nvidia's). That post was here.
Suffice to say, I moved to work in Antarctica and gave up on the project. I just picked it back up years later and decided to learn (enough) C++ to program it here. I have created the DLL, and if I place the DX code in a function, then call that function from a host "caller" program.. IT WORKS!!! However, if I put that code in the DLLMAIN, and then simply load that dll from my "caller" program (without actually calling a specific function)... the procedure executes!!! However, when it gets to the part of the code where CREATEDEVICE is run, it crashes. I have since learned this is due to an issue called deadlock, or loaderlock.. i'm not sure which. I understand the concept, but don't have anywhere NEAR the C++ understanding to develop a workaround.
So basically.. can I run my procedure in DLLMAIN using some workaround? Maybe spawning an independent thread somehow (so DLLMAIN can finish executing to it's return?) Thanks for any info. I'll include the vcproject source code here.. but it's a Frankenstein of things I found online.. so don't look for elegance- I know next to nothing about C++ programming! http://s000.tinyupload.com/index.php?file_id=07876333208461296171
The loader lock is a lock which is per-process and owned just after you call LoadLibrary, until just before the LoadLibrary returns. It is intended to ensure the process correctly accounts for the loaded DLLs and their order.
There is very little code which can be added in DllMain which doesn't run the risk of a fail, as any Windows call which may cause IPC can fall fowl of the loader-lock.
If you can create a thread from outside the process, or create a second function you can call directly, then this will be a better solution
I'm looking for a way to catch segfaults and other errors anywhere in a program (which uses multiple threads, some of which are created by external libraries). I'm using Visual Studio 2013 with the Intel C++ Compiler 2015.
Some external DLL's - in some cases I've even seen this with Windows drivers - can contain bugs that are out of my control, and my software runs 24/7 - I need to be able to log a crash somewhere and restart my software.
So far, I found that you can set a signal handler which handles SIGSEGV and other signals. Based on what I read, under Linux this would do exactly what I need (handle this signal for all threads), but under Windows you need to set the signal handler for each thread separately. Since I'm not the one who creates all the threads (if I was, I could just use __try/__catch), this isn't really an option. On top of that, I'm seeing that when I set a signal handler in a thread and then cause a SIGSEGV it doesn't get handled by the handler, while the exact same code works fine in the main thread - not sure what's going on there (but even a fix for that wouldn't help, since I don't create all the threads, and looping through all existing threads in my process to set handlers sounds like a very bad idea).
So, is there a way to do this? Googling and searching here did not help - I found several people with similar questions but no answers that are usable in my situation.
Note: What I have now, which works perfectly in the main thread but not at all if I copy this same block of code to any thread:
SignalHandlerPointer previousHandlerSEGV = signal(SIGSEGV, SignalHandler);
int *a;
a = NULL;
*a = 0;
To get notified about all unhandled exceptions in a process you can call SetUnhandledExceptionFilter. The functionality is documented as:
Issuing SetUnhandledExceptionFilter replaces the existing top-level exception filter for all existing and all future threads in the calling process.
Inside the exception filter it is recommended to trigger a call to MiniDumpWriteDump (in an external process), to produce a mini dump for off-line analysis. You get to control the amount of information that is written into the mini dump (e.g. threads, modules, call stacks, memory). Most importantly, you can dump the call stack of the thread that raised the uncaught exception, at the time the exception is raised.
As an alternative, I believe some/most/all of this can be done automatically by registering for application recovery and restart.
I am implementing a multithreaded application that invokes modules from a legacy application written using MFC.
My code runs perfectly when I run it using only one thread, but if I run it using more than one thread, I always get an assertion when CString::LoadString() invokes AfxGetResourceHandle(). The string that is invoking LoadString() is a local string, so it is not being shared at all.
If I add a mutex before the CString::LoadString() everything goes ok, but because the size of the legacy app and the common use of this method, this solution would be hard to implement and would slow down the app.
I looked into the MS documentation and it says nothing about thread-safety or so on.
Do you know something about LoadString() and multithreaded environments? All the DLLs in my app have the same character set, they all are in DEBUG mode and they all use MFC shared DLL.
Generally you can only access MFC objects from threads created with CWinThread. You didn't provide the exact assertion you got on the secondary thread, but I'm guessing your 'other' threads are created some other way. See MSDN for details on MFC vs. multithreading.
I'm facing a task of locating what is causing our production app to sporadically lock up its main/GUI thread on an end-user's machine. Unfortunately the intermittent nature of this bug and the inability to install and run any debugging/tracking tools in that environment makes locating the cause way more difficult. The current approach is to try to place traces around possible locking APIs and see which one may be causing the lock-up.
In light of that I'm curious, if there's a list of WinAPIs that call SendMessage or other locking WinAPI internally? (Which I believe may be a primary reason for deadlocks in the main thread.)
PS. I already checked the following kernel APIs that may be involved in the lock-up: WaitForSingleObject, WaitForMultipleObjects, etc. that were used in the app and all of them checked out.
On Android, I'm running an application using the NDK that runs a series of tests in C++. If ever one of the tests fails, which most likely means a crash, I'd like the application to relaunch itself and start at the next test.
I wish I could use exceptions but the NDK doesn't support them.
Is this possible?
Why does your application have to crash? Why not catch any exception being thrown? Even the compiler doesn't enforce you to add a try..catch block, RuntimeExceptions might still be thrown.
You can also use Thread.setDefaultUncaughtExceptionHandler. Note that this must be called per thread.
If, for some reason, the solutions above are not suitable for you, you could create a background service that acts as a watchdog timer.
EDIT: Check this link: for a custom version of the NDK that supports C++ exceptions. I found it in this thread.