Hi I’m currently running a beta, and some users experience problems which I just can’t reproduce - so I’m thinking about sending them debug builds and letting them run it in a debugger or in a terminal…
- Would it help to let them debug the Release build?
Usually you get errors like “Illegal instruction at 0x947F” etc. . Would there be any way for me to connect this adress to a piece of code (over debug build or release build with debug symbols)?
- Do they need to have the actual code for Debug builds to work?
I.e. will the .pdb files themselves say something like “foo.cpp, line 14” or do they need to have the codebase underneath?
- Will they even be able to start a Debug build
I remember sending someone a Debug build by accident, they couldn’t open it because they were lacking some xyzD.dll libraries.
at this point someone else has to go on because i’m still a noob however if this was my problem i’d probably try to add some functionality that writes the stacktrace into a log file or something when the plugin crashes and tell the user to send me that file… idk if that’s possible. just an idea
Using SystemStats::setApplicationCrashHandler() you can set a custom function to be called when there’s a crash. In there, you can call SystemStats::getStackBacktrace(), write that to a file, and ask the user to send over that file.
“Illegal instruction at 0x947F” etc.
If this happens on the user’s machine but not on yours, then it might indicate that your app uses CPU intrinsics (e.g. SSE4.2) that the user’s CPU doesn’t support. There are other possible reasons for this, but it’s a good thing to check.
On Windows you need to keep the exe/dll file you ship them and the pdb files created during the build process.
When the plugin/app crashes on their system you need to get a copy of the dmp minidump file it generate.
You can then use Visual Studio on your machine to look at the state of the app when the crash happened.
As I think this answer could be misunderstood, I wanted to clarify: The option you mentioned leads by no means to “all dependencies” being copied into the build. It only leads to the VS C++ runtime library being statically linked into your binary. If you add any other third party library to your project, you still have to take care for each of those libraries being linked correctly.
static void myCrashHandler (void*)
// your crash handler code
// And then somewhere in an appropriate place
Or a free function declared somewhere in your compile unit like
void crashHandlerFun (void*)
// your crash handler code
// And then somewhere in an appropriate place in the same compile unit
Edit: Just looked closer at the docs and saw that the function needs to look slightly different, as a void pointer is passed in – the docs say When called, its void* argument will contain platform-specific data about the crash.. Edited the examples above so that they take the pointer as argument but do nothing to it as the documentation tells us nothing about what kind of platform-specific data this pointer points to
Thanks for that information, didn’t want to dig deeper into the code base to find this out @ juce team, what about adding this piece of information to the docs? And maybe add some helper function that would convert that piece of information into some nicely readable string representation?
Sorry to revive an old post, but has anyone got any advice on how to handle the void* argument given to custom crash handlers as described above?
It seems really odd that I have to provide a platform-specific handler for the given data - what with JUCE being a cross-platform framework and all. Is there no way to get a meaningful description of the given error data without #if JUCE_WINDOWS, #if JUCE_MAC?
If I do have to handle it differently for each platform, what’s the recommended C++ way of doing so? It seems that for mac at least, the only option is using strsignal() which is a feature of C, not C++ (AFAIK).
That is odd, but that’s because you don’t need to do that!
The examples just above your reply are correct in that a single void function with no parameters will do the trick (ie: as described by SystemStats::CrashHandlerFunction).
static void crashHandlerFunc()
// Cues crazyparrot.gif in a web browser when the user decides to crash things.
static void superImportantInitFunction()
We’re having to provide two implementations to handle mac and windows since the data in args is different for each platform (an int on mac containing a signum, and a LPEXCEPTION_POINTERS object on windows). On mac, we’re also having to use strsignal() to get a description of the given signum which, as I understand it, is a feature of C, not C++, and there doesn’t seem to be an equivalent in the STL.
So I was hoping someone might have found a nicer, cross-platform solution for this?