I know this is an error with accessing memory outside the readspace but i have absolutely no idea how to fix this. I'm new to android, so i don't exactly know how to print out a more detailed error list from logcat in eclipse. I've tried everything from disposing literally everything, to calling System.gc to setting all my variables to null. However, whenever i switch screens the fatal signal occurs. I just need someone to tell me what exactly is going on or how i could get more details about the error.
I had the same error, what solved it was to make sure i'm on the UI thread, like this:
Gdx.app.postRunnable(new Runnable() {
#Override
public void run() {
// Your crashing code here
}
});
In my case i received same error when i try to create a new body and attach it's fixture, from beginContact (inside Contact Listener). After i moved outside Contact Listener my body creation everything was ok. Probably some conflict appears in Fixture createFixture (FixtureDef def) because according to manual: Contacts are not created until the next time step.
Related
I'm using Azure Face API for facial recognition, some of my methods are only running correctly in debug mode:
public void detectFace(MenuItem item){
getPicture();
startFaceRecognition();
}
I first noticed the issue with the code above. The getPicture() method does not seem to run if the second method is called after, though does run if the startFaceRecognition() is called from within getPicture().
public void addFace(MenuItem item){
getPicture();
AddFaceParams params = new AddFaceParams("family", "personIdCode", "", currentPhotoPath);
new AddFaceTask().execute(params);
}
The second piece of code takes a picture and then sends the picture with relevant information to Azure with a HTTP request in an asynchronous task. I believe the issue is the getPicture() method isn't being called unless there's a breakpoint placed inside the method. It works if I step through the method, but not if it is run by itself.
Would this be some form of timing issue?
I am new to Java and Android development.
We have found several cases for this kind of crashes reported by backend logging monitoring. It seems the crashes do not tie to particular UX failure. And from the reports, there is no sign of how our own classes being involved(no sign of any of our classes names). Here is an example of typical crashes:
java.lang.NullPointerException: Attempt to read from field 'int android.view.View.mViewFlags' on a null object reference
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3357)
at android.view.View.updateDisplayListIfDirty(View.java:14288)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:273)
at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:279)
at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:318)
at android.view.ViewRootImpl.draw(ViewRootImpl.java:2561)
at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2377)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2007)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1086)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6453)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:846)
at android.view.Choreographer.doCallbacks(Choreographer.java:647)
at android.view.Choreographer.doFrame(Choreographer.java:601)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:829)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:927)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:713)
Does anyone know whether there is related bug logged against Android code?
Possible Solution
I had this same issue. I setup an animation and in onAnimationEnd I was removing the object that had been animated which is when problems started. What I did was setup an asynchronous Runnable to wait 100 milliseconds after the animation had stopped before removing the animated object:
the object previously animated is this._loader
private void removeLoader() {
final ContentContainer self = this; // "CustomContainer" needs to match the type of `this`
Handler h = new Handler();
h.postAtTime(new Runnable() {
#Override
public void run() {
MainActivity.instance.runOnUiThread(new Runnable() {
#Override
public void run() {
try {
if(self._loader == null) {
// there is no loader. quit now while you still have the chance!!
return;
}
while(self._loader.getParent() != null) {
removeView(self._loader);
}
} catch(Exception e) {
Crashlytics.logException(e);
e.printStackTrace();
}
self._loader = null;
}
});
}
}, 100);
}
Cheers
I was facing same problem. I resolved with Handler.
new Handler(Looper.getMainLooper()).post(new Runnable() {
#Override
public void run() {
// remove fragment from here
}
});
The problem is in the ViewGroup's dispatchDraw() method. This method tries to draw all the ViewGroup's children. When a child is null, you get an exception, which most likely comes from this line: if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE) { (notice the mViewFlags).
So the problem is that one of your views, somewhere, is not properly initialized. I'm afraid that's the best I can do.
We started getting this error unexpectedly too. It was tracked down to fragment animations being the issue. More specifically using custom animations with replace() in a fragment transaction when the app is built against Local Maven repository for Support Libraries rev > 26.
Possible solution
Downgrade Local Maven repository for Support Libraries to rev 26. See here
Possible cause:
I was having the exact same issue. It turned out it started to happen when I added code to modify the view tree within onDraw() call. To be specific, I removed a view with children in my derived onDraw() when certain conditions were met. I now believe this is a bad thing to do, probably because the platform is trying to draw views that I have now removed from the view tree. I resolved the issue by posting the deletion with Runnable to happen after the call to onDraw() has finished.
Override dispatchDraw method and put in it a try/catch block, like this:
public void dispatchDraw(Canvas c)
{
try
{
super.dispatchDraw(c);
return;
}
catch(Exception exception)
{
return;
}
}
While it is ugly and not good practice, the only thing I could get to reliably work is just catching the exception in dispatchDraw() like below:
override fun dispatchDraw(canvas: Canvas?) {
/*
* We're doing this because of the below exception that is out of our control:
* java.lang.NullPointerException: Attempt to read from field
* 'int android.view.View.mViewFlags' on a null object reference at
* android.view.ViewGroup.dispatchDraw(ViewGroup.java:4111)
*/
try {
super.dispatchDraw(canvas)
} catch (e: NullPointerException) {
}
}
Just make sure your desired behavior is working correctly and you're not breaking something else by doing this.
Again, not ideal, but it's the only thing I could get to work and I'm absolutely sure in my case it's not breaking anything else.
Peace to you :)
I was trying to navigate from Fragment A to Fragment B, and Fragment A was a form that required data from Fragment B.
So when I tried to navigate without filling up A, it was throwing this exception.
Also, even if A was independent of the data B, it was throwing this exception.
I have no idea why but I added a condition where the user had to fill-up the form before navigating away and that solved the issue.
It's a threading issue. Could be that you're refreshing your ViewPager or some other adapter.
Have been facing this issue on and off, and realised that if you place it in the UI Thread in your Activity, then it'll render just fine.
activity?.runOnUiThread{
// Add Your UI Updating Methods Here
}
No delay / threading stuff required. Plz Read through...
The post is old but for the future readers, it would be helpful.
I explain in details what really happens with a use-case I faced and solved.
I have a viewflipper which animates flipping next and previous through its children using simple slide-in / slide-out animations. I need to remove a view from viewflipper just after flipping is completed and to make sure it happens at the right time, slide-in animations have a listener where I remove the view in there. Everything worked perfect for flip-to-next
while flip-to-previous threw the above mentioned exception. After some trial and error turns out:
when flipping to next the following is the sequence:
1-slide-out starts
2-slide-in starts
3-slide-out finishes
4-slide-in finishes
So having listener on slide-in is the right thing since both animations are guaranteed to be completed there.
But when flipping to previous the following is the sequence:
1-slide-in starts
2-slide-out starts
3-slide-in finishes
4-slide-out finishes
As you can see, when slide-in finishes, slide-out is not done yet and hence there happens the exception. I simply set the listener on slide-out and it worked perfectly.
While all of the other answers urge to remove the view with a delay (which of course helps to make sure concurrent animations are all done) but as you could see that is not the case.
As a general rule, when you have a set of animations running on a view (even with the exact same durations) -although the general belief is that they would finish both together - but they won't (remember that threads are virtually concurrent).
This is mainly because you are removing a view duaring touchEvent dispatching.
It's hard to find out the who is removing the view in a large code base.
For those who want the crash analysis, can check this post:
https://medium.com/#wanxiao1994/crash-analysis-resetcancelnextupflag-nullpointerexception-e409b7bdbad
I'm trying to set FLAG_SHOW_WHEN_LOCKED in my phonegap app, but only when a certain page is shown. To do so, I have a Java plugin extending from CordovaPlugin with the following code in the execute method:
if (action.equals("showWhenLocked")) {
boolean showWhenLocked = args.getBoolean(0);
if (showWhenLocked) {
this.cordova.getActivity().getWindow().addFlags(WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);
} else {
this.cordova.getActivity().getWindow().clearFlags(WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);
}
callbackContext.success();
return true;
}
It gets called with cordova.exec(null, null, 'MyPluginClass', 'showWhenLocked', [myVar]), but on execution I get the error
Uncaught Error: Error calling method on NPObject. at file:///android_asset/www/cordova-2.2.0.js:984
Any ideas what's causing this/what I'm doing wrong and how to fix it? If I set the flag upon creating the activity it works just fine.
I have found already that this kind of error can be caused by calls that require threads that are not available. Your use of getWindow() tell me that this is even more likely. You are most likely accessing information locked by another thread, like the UI thread. Check out the cordova documentation in the section about threading in the UI thread.
Using:
callbackContext.success();
will explicitly call the success callback but in your case the success callback is null so that is why you get the error.
Try using:
callbackContext.sendPluginResult(new PluginResult(PluginResult.Status.OK));
that way the exec call returns but the JS will check to see if there is a success callback before trying to call it.
Adding android-support-v4.jar to project build path and checking it's entry in Order and Export (tab) of Build path works for me . - Thanks, Prodeveloper
A similar question was asked here for two times and never there was any answer. Or the answer was: "it is impossible!" Sorry, it is possible too much:
try{
...
// the line that causes the error
LinearLayout cell = (LinearLayout) inflater.inflate(R.layout.channels_list_cell, column);
...
}
catch(Throwable e){
Toast.makeText(this, e.toString(), Toast.LENGTH_LONG).show(); < breakpoint here!
}
At the breakpoint e is null. How can I seek for the error, please? Very possibly it is not the problem of java or Android, but of the Eclipse debugger, that itself needs debugging badly. But what have I to do, except changing to a different IDE? Any ideas? Beforehand grateful.
I have tried Throwable, Exception, RuntimeException. The result is the same.
An attempt to step over breakpoint causes NullPointerException, so, e seems really null at that moment already. Where could it be lost?
Edit:
I bring my gratitude to everybody and +1 to every answerer. It was an Eclipse bug. After restart Eclipse the Exception is not null anymore, it is a normal RuntimeException: Binary XML file line #15: You must supply a layout_width attribute. It would be another problem to be solved, but that one is solved.
If the exception you caught was a NullPointerException, the getMessage() method returns "null" which may be confusing. I know that this has sometimes confused me!
In the debugger, you should be able to select e and see a type and its fields. Also, another way to debug when things get really confusing is to go
e.printStackTrace();
(note - I'm not an Android guru so if this works differently on Android somebody please comment!)
Have you verified whether e is actually null or not? I.e. by adding something like if (e == null) Log.d("Exception is null"). I would then check if the log statement gets triggered both during normal execution and while debugging. If the results are different between the two, it would indicate a VM bug (unlikely, but possible). If the message doesn't get triggered in either case, then it's likely a debugger issue.
A few thoughts on further things you can try to debug the issue:
Try something like jdb and see if you get the same behaviour
You could get a dump of the jdwp communications between the debugger and the device, and see what's going on at that level. Maybe use wireshark or tcpdump and grab the data going over the usb bus to the device.
You could try adding some debug statements to dalvik itself. E.g. grab a copy of AOSP and build an emulator image, and then add some debugging statements to dalvik to try and track down what's going on.
You could attempt to do some sort of scripted jdwp session with the device
You could look at the bytecode (baksmali/dexdump/dedexer), to see if anything looks funny
Android does not always throws exception in a Throwable. It actually drives all the exceptions to the catLog. There you will find details of your exceptions even if in the catch block your exception is null.
You can easily access the catlog console from eclipse and filter to view the errors only
UPDATE:
Your breakpoint should be inside the catch block
I know this question was posted a while ago, and many times too! I fell into this trap yesterday and I thought I'll post what I found.
Problem definition: I used the following code
public class myAppActivity extends Activity
{
/** Called when the activity is first created. */
#Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
try { -- lots of code -- }
catch (Exception ex) {
Log.e ("eTutorPrism Error", "Caught this exception " + ex);
ex.printStackTrace();
}
}
}
Symptom was that 'ex' was always null and resume will give NullPointerException, although the actual exception was an IllegalArgumentException in a call made into another class from the code above.
ISSUE: onCreate() code does not display the exception caught. instead it shows exception = null.
Solution: do NOT use too much processing in onCreate(). Move as much as possible to another thread. So I changed the code to look like the following. voila, it works!!! I can see the actual exception displayed in the Logcat.
public class eTutorPrismAppActivity extends Activity
{
/** Called when the activity is first created. */
#Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
eTutorPrismTest myTest = new eTutorPrismTest (getApplicationContext());
myTest.start();
}
}
class eTutorPrismTest extends Thread
{
private Context m_AppContext = null;
public eTutorPrismTest (Context appContext)
{
m_AppContext = appContext;
}
public void run ()
{
-- lots of code that needs appContext --
}
}
I am unsure of what causes this -- it could be an Eclipse bug as stated earlier. Regardless of the cause, I did find a workaround that seems to work. I hope it is useful to others as well.
After the exception is caught, assign it to another variable. The assigned variable should contain the correct Exception in the debugger.
SpecificException assignedVar = null;
try {
...
}
catch (SpecificException exc) {
assignedVar = exc; // <-- exc comes up null in the debugger, but assignedVar will be the correct object.
}
Hope this works for others as a workaround.
ok so i've nearly got this. But it seems there is some logic error that i can't get around. Note that i cannot use try/catch. No need to ask why
EDIT
for(String File : List){
final String FilePath = getPath() + "/" + File;
Render renderer = renderFile(FilePath);
Runtime.getRuntime().addShutdownHook(new Thread(){
public void run() {
deleteFile(FilePath);
}
});
deleteFile(FilePath);
updateReport(stuff);
writeReportToFile(Report.toString());
I want it to delete the file that's causing my crash .. if the app crashes but it doesn't seem to be working. Am i calling it wrongly or what? confused
FINAL EDIT
OK after much toying around i finally got it to work!! Thanks everyone
From your last question I see, that you
process images,
one or more images will crash the JVM,
we can't catch that exception/error and
we want to delete the corrupt image on the next run
An easy solution goes like that:
Each time, before you read bytes from an image file, persist the name of that image to a file (like: processingImage.txt)
Each time, an image has been processed succesfully, delete processingImage.txt
If the application crashes, then processingImage.txt contains the name of the offending image
If you start the application, check if processingImage.txt exists, read the name of the image, delete the image and delete processingImage.txt.
I have a bad feeling about this, but you could add a shutdown hook on your application. (Be warned, while the shutdown hooks are processed, the only way to kill your application is via task manager - so be sure that your shutdown hook really works/does not take forever/does not cause deadlocks)
The following main
public static void main(String[] args) {
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
System.out.println("I'm called on shutown.");
}
});
throw new RuntimeException("Uncaught Exception");
}
prints this:
Exception in thread "main" java.lang.RuntimeException: Uncaught Exception
at stackoverflowtests.ShutdownHookTester.main(ShutdownHookTester.java:11)
I'm called on shutown.