User Profile

I use Crashlytics to generate crash reports for an iOS app. When C++ exceptions are thrown on the main thread, they are caught by a CFRunLoop exception handler and rethrown, which destroys all the information about where in the code the original exception is thrown.There is an open radar for this, opened two years ago, that was marked as "duplicate", but the duplicate doesn't exist as far as I can tell: http://www.openradar.me/radar?id=4943586562932736This is a Stackoverflow thread about the issue: https://stackoverflow.com/questions/13777446/ios-how-to-get-stack-trace-of-an-unhandled-stdexceptionI've tried all sorts of workarounds, including printing the stack trace with [NSThread callStackSymbols] in the constructor for the exception I use. This sort of works in debug builds (at least I can see the trace, but Crashlytics still lumps them all into "std::terminate"). But this does not work in release builds. The symbols are random symbols that don't correspond at all to the actual stack trace. The end result is that I have no usable stack information for any crashes on the main thread from C++ exceptions, which is unfortunate because my whole app is written in C++.It's been several years since this was reported to Apple. The proper solution is to allow us to turn off the CFRunLoop exception trapper. Should I file another radar (hopefully it won't also be closed as duplicate) or what else should I do to draw Apple's attention to this? Being unable to report C++ exceptions is a pretty big deal.