Re: Google Crash Handler 32 Bits Que Es
Lee Lucario
The full documentation is available here. If you spend two minutes configuring this (I have the last 30 crashes saved as full dumps in c:\temp\crashdumps) then you will be better able to investigate crashes on your machine, regardless of what process is crashing.
Stefan Reinalter pointed out that some libraries will handle errors by calling abort(), and this can be another way for a process to fail without your crash handler being called. He also supplied the fix, which is to call signal(SIGABRT, &AbortHandler); to install a handler which will be called if abort() is called. Signal can also be used to install handlers for other types of failures.
However I think the main reason for crashing at the first sign of trouble is that this is the only way to be sure that the problem is taken seriously. Far too many teams ignore warnings of all types, whether these be compiler warnings, linker warnings, asserts, or crashes that are handled. Whether during testing or during production all teams know that crashes must be taken seriously and must be investigated.
A sane language that wraps Win32 exceptions sounds like an oxymoron to me. Python uses exceptions for its error handling but if it silently handled an access violation and translated it into a Python exception I would be disappointed.
I said in the article that my preferred implementation was __debugbreak() followed by TerminateProcess(), to ensure that a crash occurs and either drops into the debugger or saves a minidump, followed by exiting.
Ah, I thought the __debugbreak() was just for purecall, invalid parameter and abort(), and that unhandled exceptions somehow deserved different treatment. Thanks for the reply, and thanks for the excellent set of articles so far!
I know one of the long standing rules is don't beta test products together, it makes for unreliable results. I'm a Windows Insider as well as an Edge Insider and it's not just practical for me to have a seperate machine or VM or every possible outcome there is. With that being said; is there a crash handler available, such as the old Dr. Watson that can I can use to capture crash data when Edge is crashing because it crashes allot (for me I define a lot as more than 5 times in a day).
TortoiseSVN has used its own crash handler since the very first release. If TortoiseSVN crashed for any reason, a dialog is shown which allowed you to send the crash dump to us. We then analyze those crashes and fix whatever caused them. This helped us to make TortoiseSVN much more stable (stop laughing, it could be worse!).For a long time, sending the crash dumps to us only worked via email. With Version 1.7.6 that changed: we started using crashrpt which allows to send the reports via http.While before 1.7.6 we got maybe 4-8 reports a day, now that changed to +100 reports per day! I guess that most of you either only used web mail or didn't wanted to send the reports from your email account. With the http send, this isn't an issue anymore and that's why we now get so many reports.As you can imagine, it's simply not possible to analyze that many reports manually anymore. So as of version 1.7.7 we're switching our crash reporter once again. But not back to an email-sending one, but one that offers a lot more features: drdump.com.drdump.comThe crash handler from drdump.com is not just a client side handler, but offers automatic analysis on the server side as well. All reports that are caused by the same crash are automatically grouped together, so we only have to analyze the best dump file of a crash instead of every single one. Without this, there's no way we could handle all the reports we now get!
Also instead of only sending a minidump, it can send us a full dump if the crash hasn't been previously reported. We also can ask for a full dump in case the minidump we have does not provide enough information to fix the problem.Another nice feature is that after you've sent the crash report and the problem you're experiencing has already been fixed, you're automatically forwarded to the corresponding page in our issue tracker. There you can find out more about your problem and decide for yourself if you want to download a nightly build or not.drdump.com is available for free for open source projects. Pricing for commercial projects is shown here. If you want to find out more about how this works, there is a nice video available that explains the basics, a more detailed description and a tutorial on how to integrate it into your own application.Always send the reportsWith so many crash reports we get, we simply don't have the time to analyze every single one of them and that's why we rely on the grouping of the reports on drdump.com. Every sent report is first automatically analyzed and if the same crash was already reported before moved to the corresponding problem. That problem then has its crash count increased.As you can imagine, we try to fix the problems with the highest crash count first. If you encounter a crash, then please send the report. It will increase the crash count of the problem and therefore also increase the priority for us to fix it.
I think this may be difficult as a crash inside the plug-in will also bring down the host. It is possible to get a stack-trace by getting a callback when the app crashes (via signals) but hosts will typically override this as well to do there own crash reporting.
From conducting a narrowly scoped test it looks like SystemStats::setApplicationCrashHandler() seems to work in a plugin running in a host. Within the callback it can get the stack trace via SystemStats::getStackBacktrace() and write it to a file. However, from poking around online it seems that running code in a process that has "crashed" is quite risky. Some people have recomended using fork() to open up a new process to conduct the reporting. I see there's some support for accessing the current process in Process::, but is there a juce way to create a new process?
I scout for crash logs the next time the plugin is opened ... that works on the Mac. I think Microsoft have a service where they'll send you the crash logs from their crash reporting service ... never tried it.
Apparently Apple will, too, but you have to have your app registered through the App Store. Scanning upon opening is a good idea. I've gotten Crashlytics working for 64 bit OS X JUCE apps (working on 32 bit with their support). I'll keep you posted about the plugin situation.
Interestingly enough, if you set a functionin SystemStats::setApplicationCrashHandler() within your juce plugin (say in the AudioProcessor constructor) & cause a crash within your plugin code, the OS X crash report won't be generated (but your crash handler code will). I've seen this kind of "hijacking" occur in Logic Pro & Reaper so far. I haven't tested if the same happens when another plugin, instantiated side by side with yours, causes the crash.
Now I know in the docs it says "The usefulness of the result will depend on the level of debug symbols that are available in the executable." If I could just get function names & line numbers I'd be a very happy camper. Does anybody have any experience with re-symbolcating before I dive in?
If the host has been configured to create minidumps or macOS crash logs correctly, you can get users to send you these though. As long as you have the PDB files, you should be able to debug the minidump for your sections of the code.
In case of Windows, the built-in infrastructure is called Windows Error Reporting (formerly known as Dr. Watson). If an application crashes, WER takes over and displays a well-known dialog about the crash, and collects some data. If the user consents, the report is sent to Microsoft. If you code sign your application and register at the Windows Dev Center, you can access reports for your application.
Unlike x86 which has frame pointer chains and a linked list of exception handlers that are currently in scope, x64 has metadata-based exception handling. (Almost) every function has an associated block of metadata, which describes its prolog (its stack layout and usage, essentially) and exception handlers contained in the function (if any). To traverse stack frames and find exception handlers, the system relies on the presence of this metadata.
What we need to do here is create a so-called runtime exception helper DLL with some predefined exported callbacks, register that DLL, and in our application (at runtime) tell WER that we want this DLL to potentially handle our crashes. The said DLL must:
I have completely set up the connection to the micro:bit after figuring out how to get it to work, and App Inventor has no problem communicating with the micro:bit except for a slight delay.
However, my problem is that App Inventor cannot handle any inputs from the micro:bit, specifically when I press a button on the micro:bit.
Whenever I try to do this, the app on my phone crashes, which is very frustrating because I cannot get the micro:bit to communicate with App Inventor without it crashing.
So just to confirm that I understand correctly, you're saying that you set up everything successfully on the App Inventor side using the MicrobitButton component and a corresponding BluetoothLE component and everything there is good up until you press the button on the micro:bit? Normally if a crash would occur, I'd expect it to be earlier in the chain and it's usually due to having changed the HEX file running on the micro:bit. Does this happen with only an empty event handler for when the button is pressed?
It seems to have to do with some sort of incompatibility issue in my phone (Moto Z2, runs Android 8)?
I managed to acquire an older Android tablet (Asus MeMO Pad 7, runs Android 5) and it worked like a charm.