I'm constantly hitting "Unable to get JNI Environment pointer!" error but cannot track down it origins. It's appearing after garbage collection (it's no different if I call GC.Collect or garbage collection occurs automatically) and then application crashes. An example log output:
I/monodroid-gc(15423): GC cleanup summary: 92 objects tested - resurrecting 71.
F/Mono.Android(15423): Unable to get JNI Environment pointer!
I/ActivityManager( 2679): Process LuntikAndroid9.LuntikAndroid9 (pid 15423) has
died.
What can cause such an error? I'm trying to reproduce it in self contained code snippet but no luck so far.
This bug was fixed in the 4.0 release.
Related
I've enabled crashlytics and trying to log with following code. I'm getting this warning. Can't figure out what this warning is and how to fix it.
In other words how do I log using CLSNSLogv?
Crashlytics:Crash] WARNING: CLSLog has been used before (or concurrently with) Crashlytics initialization and cannot be recorded. The message was:
CLSNSLogv("load() %# %d", getVaList(["Array count:", self.array.count]))
I'm the person that wrote that error message in the Crashlytics SDK :) However, I no longer work with that group and it's been a long time since I worked on that project. So, your best bet is to reach out to their support people.
Unless things have changed internally, the error message is telling you exactly what's up. Your use of CLSLog isn't the issue. The problem is the timing of its invocation. You cannot use the CLSLog family of functions until after the Crashlytics SDK has been fully initialized. It initializes synchronously. So, you can safely use CLSLog on the very next line after the Crashlytics SDK initialization call.
Perhaps you are invoking CLSLog in a function that's called asynchronously during startup?
Or, maybe you are initializing Crashlytics on a background thread? There are situations that cannot be reliably handled if you init the SDK asynchronously. I wouldn't recommend it, personally, but that's a call you have to make. I just want to make sure you understand the performance/correctness tradeoffs.
I have met the following messages in the console at runtime, and i have no idea why. I have searched everywhere and nobody seems to meet this:
INFO: fetch-response is unable to open the file /Users/userName/Library/Application Support/iPhone Simulator/7.0.3/Applications/964A590B-7131-4BAE-958B-1783BEC193EF/Library/Caches/userName.AppName/fsCachedData/2F1A8708-35A9-491E-9C21-154BA428CA10. Errno: 2
ERROR: failed to mmap cache data from FS: /Users/userName/Library/Application Support/iPhone Simulator/7.0.3/Applications/964A590B-7131-4BAE-958B-1783BEC193EF/Library/Caches/userName.AppName/fsCachedData/83A968D1-0A2B-4D20-97D5-487A876649DC, errno:22
It does not seem to affect the execution though, but I suppose it is not a good sign. I am using Core Data with a timer which frequently updates the database from a server. These messages appear synchronously with the updates, but not systematically. Only one at the time, the "INFO" or the "ERROR". Reset Content and Settings in the Simulator did not solve the problem.
Does anyone have any idea about the meaning of these messages?
I experienced this when running on my device with an app I am building. It has worked perfect for weeks and then all of a sudden this error. I figured out that it is due to a lack of memory available on the device. I use a little app call "System Status" that allows you to view the memory stats and release any old unused memory. I only get this error in Xcode when I have less than 5% available memory on my device. Therefore it cannot load the cache file the app is request, hence the error. Either close all your multitasking apps and restart your device or get the app and free you memory.
After some testing/debugging (sorry for the delay), I have at least a temporary solution.
Because of the multi-threaded saving process of Core Data, I found it a little tricky to identify the exact error location, but it definitely appears that the error occurs when Core Data is trying to save one of the context in the stack (probably the last "root" one).
As each save take a few seconds (without freezing the UI :p) , I figured the error could be generated by a "save overlap".
So even if I do not have enough to be sure, reducing the save frequency effectively solved my problem: no message anymore in the output.
Now there still is a hitch, and any expert answer would be much appreciated!
Uninstalling the app from the device and installing it again removes this error message.
Note that that doesn't fix the problem if you can see this log from earlier versions of your app that is already on your users' devices. It's generally okay to uninstall-install, though, if you're only seeing this during the development phase.
For me this happened when my phone ran out of batteries and died as a result. Deleting the app, then restarting my phone, then rebuilding/installing solved the problem.
I ran into this error because my app was stuck in an infinite loop, doing network requests multiple times a second, causing the file to be overwritten before it could be read.
In the situation described in the original post, this might very well be the case.
I have created an iOS app and need to check the leaks in the app programmatically.
(Hence not using instruments directly)
For the above I use the leaks command as follows:
MallocStackLogging=1 leaks -nocontext
At one point of time this was working properly without issues. But recently I have started getting errors and the leaks commands gives different number of leaks each time.
Has anyone faced a similar issue?
You can programmatically find the current memory stats using vm_statics object. Go through these links to find an implementation of vm_statistics:
1)
http://gamesfromwithin.com/whered-that-memory-go
2)
http://landonf.bikemonkey.org/code/iphone/Determining_Available_Memory.20081203.html
I added the below environment variables to my Project and set their values to YES.
NSDebugEnabled
NSZombieEnabled
MallocStackLogging
MallocStackLoggingNoCompact
I followed the Procedures in http://www.cocoadev.com/index.pl?DebuggingAutorelease
I was able to find the Problem based on the Log generated. My doubt is when I tried to find the stack trace to find where the object was allocated, I got the below information:
malloc_history cannot examine process 6963 because the process does not exist.
Am I missing anything here?
Below is the Log Created:
UPDATE:
I found the below link to be a good source of information on this:
strange GDB error unable to trace
I am yet to test this.
I've found for myself, that malloc_history is unable to track memory log of the device while successfully tracking the simulators memory log. Try to simulate the problem on simulator and then use the malloc_history tool. (at least I've found it as the only way yet)
Synatax:
Shell malloc_history process_id memory_address
Keep the track of processid Use the one when application starts.
Our DUnit project is crashing on exit. It crashes if "Run Without Debugging", but doesn't crash if I Run inside the debugger.
If I attach the debugger to the process after starting it, it does not crash on exit.
I suspected a problem in finalization, so I put print statements in all the finalization code I suspected was running. This turned up nothing useful. Finalization for one of our low level Units (with no dependencies on any non-system Units) is running correctly. So it still could be finalization, but it may not be.
The crash produces this dialog:
Problem signature:
Problem Event Name: APPCRASH
Application Name: MCLTesting.exe
Application Version: 0.0.0.0
Application Timestamp: 4eb07b50
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18215
Fault Module Timestamp: 49953395
Exception Code: c0000005
Exception Offset: 000bf395
OS Version: 6.0.6001.2.1.0.256.6
Locale ID: 3081
Additional Information 1: b37c
Additional Information 2: 2a7328d8bb40c81c93b4b5f46adb8e10
Additional Information 3: b37c
Additional Information 4: 2a7328d8bb40c81c93b4b5f46adb8e10
"Exception Code: c0000005" Does that mean anything?
The main clue I have is the fact that it doesn't crash in the debugger. Has anyone seen that before?
I finally tracked this down.
The problem was indeed in a finalizer. A user exception was being thrown in a finalizer. The exception was not caught, and the exception itself was being leaked (The Exception and its string were not freed). It seems this memory leak was causing the crash? I'm not sure why I didn't notice this memory leak when I originally posted.
Catching the exception fixed the crash problem.
One interesting thing I found out is that even if an uncaught exception is thrown in a finalizer, subsequent Unit's finalizers will still be run. I was assuming that a problem in one finalizer would stop all subsequent finalizers from running.
The method I used to find the offending Unit was very simple; I removed all units from my project, then reintroduced Units one by one until I got the crash bug. Time consuming but it worked in the end.
Exception code c0000005 is an access violation. This usually means one of two things: either you're attempting to dereference a pointer or object reference that's set to nil, or you're working with corrupted memory.
The other pertinent piece of data in the error report is Exception Offset: 000bf395. That tells you where the error is occurring. Try looking up f395 in your map file and see if you can't find a unit finalization that corresponds to that memory offset. If so, that should give you a good idea as to what's going wrong.