Crashlytics for ndk can't access system unwind with error info: Failed to find any usable unwinding libraries on the device, falling back to simple unwinding
Maybe this failure caused that we only got one line for the native crash.
My device is Nexus 6 with platform 7.1.1
Mike from Fabric here. Yes, if we're unable to find libcorkscrew and libunwind then we switch to our own simple unwinder. The simple unwinder is only able to get the top-most frame in a crash which is why you're seeing this behavior. We plan on making this better.
Related
What is the best tool to debug core files generated by nodejs, we are using node version 0.10.X.
I was looking through https://github.com/nodejs/llnode which is a nodejs plugin for LLDB, but seems to work with v4.X/v6.X
Any pointer is appreciated.
With regards,
-M-
If the requirement is for a specific crash dump, I would look at the failing context before deciding a debugger - for example:
(i) If the crash is in C code (libuv, c-cares etc) a native debugger for your platform (gdb|dbx|lldb|windbg...) will do a great job to navigate through the frames.
(ii) If the crash is in C++ (node.js core), same applies.
(iii) If the crash is in JS (core libraries | app) please see if IDDE is of some help - this provides sophisticated abstractions over the core file structures.
lldb/llnode https://www.npmjs.com/package/llnode is the recommended tool for analyzing core dumps from nodejs, but yes it only supports node4 and later. I'd suggest trying your platform debugger, eg gdb for linux, to get the native stack at least, as in the answer from Gireesh.
Note that node0.10 went end-of-life in 2016, see https://github.com/nodejs/LTS#lts-schedule1.
I've looked into other questions relating to grade issues and I cannot find anything that relates to the cause I am seeing.
I am learning to develop android applications as part of my independent study programming course. Because this is being done on a school computer, I have been dealing with some odd behavior from android studio.
Most of the issues I was able to fix, but there is one that I cannot find a solution to, and it is locking me out of any debugging tools and the Android Device Manager.
Almost immediately after loading a project, I get an error saying "grade sync failed" and am pointed towards a massive stack dump. Gradle attempts to create a file lock on some file that I cannot identify. An UnsupportedOperationException is thrown with the message "File locking is not supported".
So I came up with a possible solution. This is almost certainly being caused by the VM nature of the environment I'm using, so would moving the android SDK and gradle tools to my flash drive fix the problem? (64G, file size isn't an issue). Where are those grade files stored and how can I instruct Android studio to their new location?
Side note that I do not have any administrative permissions.
I want to profile a MonoTouch application in Instruments without an iPad. I am able to profile an app compiled for Simulator but it's no fun without the symbols:
There is no option to generate IPA with dSYM in project build settings—looks like they're only available when compiling for the device.
All I want is a MonoTouch-aware dSYM for Simulator.
Is this possible?
This is unfortunately not possible, because in the simulator we JIT managed code. This means that it is not possible to know before executing the process where methods will be in memory, and Instruments doesn't support the required mechanisms for MonoTouch to inform about JIT'ed methods at runtime [1].
[1] See last comment on the response here: Is it possible to notify DTrace on Mac OS X of dynamically generated code?
Take a look at this - miguel wrote a blog post recently to compile aot for profiling on mac - I think this will give you what you're looking for:
Using Instruments to profile Mac apps built with Mono
I've been searching around and can't seem to find a definitive reference on how to use the TestFlight SDK with MonoTouch... has anyone gotten it to work successfully with 0.8.3 and mind sharing their secret?
Testflight documentation can be found here:
http://docs.xamarin.com/ios/tutorials/TestFlight_Support#
The Testflight bindings can be found here:
https://github.com/mono/monotouch-bindings/tree/master/TestFlight
Instructions about building are also on Github following the link above. Basically you just have to run "make" from the TestFlight folder (but copy the appropriate TestFlightSDK_xxx.zip file into that folder first).
The Make file included in the github repo utilizes the TestFlight SDK (a zip file) which must be independently downloaded from TestFlightApp.com and manually copied (in compressed form) into the folder containing the binding project from github.
Then use Testflight SDK as explained on the Testflight website (call TakeOff(), set checkpoints, etc.).
Maybe try the bindings from ayoung and follow his readme.
https://github.com/ayoung/monotouch-testflight
From my own research and trials trying to get the TestFlight SDK to work with MonoTouch, it seems that the error reporting won't really work. Here's why:
Essentially, the TestFlight SDK inserts an obj-c global exception handler and then sends the exceptions, stack traces, etc. to TestFlight. Since the SDK is a NATIVE library, it will only wind up receiving native obj-c exceptions. This means that none of your Mono exceptions will ever reach this global obj-c handler because the handler is running at a lower level than the Mono runtime.
So, you CAN bind to the native TestFlight SDK library, you CAN call the TakeOff() method, etc. But at the end of the day, it's all kind of pointless because your Mono-level exceptions will never be caught. You could certainly receive obj-c exceptions when they occur, but this doesn't really help you with your Mono exceptions. Since all your code is presumably in C# running in the Mono runtime, don't expect your exceptions to hit the TestFlight SDK handler.
If I'm wrong, someone please correct me, but I don't believe the TestFlight SDK will be useful until a MonoTouch library is written that intercepts Mono exceptions and sends those to TestFlight.
I got a game written in C/C++ using GLES v1.1 (yeah that was an iPhone game), as Im porting it to android I realize that I got some logs on the LogChat of Eclipse that tells me that the GL functionality (like glGet*) that I want to use is not implemented.
Digging on Google I found that you can cast a GL10 to GL11 context, however, since my API calls are all native, I cannot use that...
Is there a way to initialize a GL11 context in Java and then use the native GL11 API call?
If you are running on the emulator, be aware that currently (SDK Tools Rev9, ndk-r5b) the emulator (no matter the platform version) only implements the GLES 1.0 interfaces. It won't matter that your context is for GL11. You'll need to test on hardware to successfully call the unimplemented API entry points.