Fixed
Status Update
No update yet.
Comments
vi...@google.com
I see same issue and have been debugging it.
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
mi...@gmail.com
[Comment deleted]
si...@busybusy.com
But Google pls fix this issue, as the expected behaviors must be consistent with ICS DialogFragment + FragmentManager and support package DialogFragment + FragmentManager.
It happens with both Support Package v4 r6 and v13 r6.
It happens with both Support Package v4 r6 and v13 r6.
ka...@sentry.io
I have this problem too.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
mi...@gmail.com
This is definitely not a bug. There are times when onActivityResult() can be called before the Activity has restored its saved state... committing fragment transactions in these situations will simply not be remembered as a result (see this blog post: http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html ).
Try moving your commits into "onPostResume()" instead as described here:http://stackoverflow.com/questions/16265733/failure-delivering-result-onactivityforresult/18345899#18345899
Try moving your commits into "onPostResume()" instead as described here:
vi...@google.com
Adding a "super.onActivityResult(requestCode, resultCode, data)" call at the beginning of the method seems to fix the problem. I'm surprised than almost nobody came up with such a simple solution.
ka...@sentry.io
Dear alockw...@google.com,
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
Description
Description of the problem:
When two threads concurrently invoke
Debug.stopMethodTracing()the ART willSIGABRTwith:While this was recorded on a Default Android System Image 14.0 running on the emulator, a customer saw this on Android 13 and 14 in the field with no device-specific bias.
Further details regarding the bug on the
How to reproduce
I used a vanilla app template from Android Studio and executed the following code from a button click:
I don't think the number of threads (I was able to repro with 2), the parameters used, or the timing is relevant, but with this code, I could reproduce the
SIGABRTon every run.While this particular code won't be found in an app in the wild, multiple app dependencies could call
Debug.stopMethodTracing()simultaneously.Expected behavior
Instead of terminating the application with a
SIGABRT, thepthread_join()insideTrace::StopTracing()should be guarded correctly so thatpthread_join()isn't called twice for the sampling thread. Logging a non-fatal error can make sense, but since the function expects to be called from multiple threads, I am unsure if that log adds much value.Suggested fix
Resetting the member
sampling_thread_[1] should happen immediately after callingpthread_join[2]. Ideally, this would happen at the end of the firsttrace_lock_scope [3] so that thread-join and -reset happen atomically.I can provide the change in Gerrit if that helps.
[1]https://cs.android.com/android/_/android/platform/art/+/main:runtime/trace.cc;l=969
[2]https://cs.android.com/android/_/android/platform/art/+/main:runtime/trace.cc;l=914-919
[3]https://cs.android.com/android/_/android/platform/art/+/main:runtime/trace.cc;l=902-912