Fixed
Status Update
Comments
p....@catenacyber.fr <p....@catenacyber.fr> #2
added bugreport
ja...@google.com <ja...@google.com> #3
Hi,
I am not observing any crash on NDP3 on Nexus 5x even after following the steps provided. So please provide the video of the issue.
Screen Record of the Issue
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.
Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.
Also mention the frequency of the issue.
I am not observing any crash on NDP3 on Nexus 5x even after following the steps provided. So please provide the video of the issue.
Screen Record of the Issue
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.
Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.
Also mention the frequency of the issue.
p....@catenacyber.fr <p....@catenacyber.fr> #4
Here is the video. this occurs every time I go to the home screen from this search result.
Video:https://drive.google.com/file/d/0B-eHYVYyBpyjUjExemRVYTk5bXM/view?usp=sharing
APK:https://drive.google.com/open?id=0B-eHYVYyBpyjQmQ2UnpacDVFVkU
This only occurs on a build of my app that has a compileSdkVersion / targetSdkVersion of N . Does not affect current production APK that targets Marshmallow
Video:
APK:
This only occurs on a build of my app that has a compileSdkVersion / targetSdkVersion of N . Does not affect current production APK that targets Marshmallow
p....@catenacyber.fr <p....@catenacyber.fr> #5
Hi,
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks
sc...@gmail.com <sc...@gmail.com> #6
[Comment deleted]
p....@catenacyber.fr <p....@catenacyber.fr> #7
Looks like I have the similar issue on targetSdkVersion 24 and in my case it relates to huge saved state.
Moreover, looks like on compile/targetSdkVersion = 23 we have only internal warning about large size of saved state, but nothing is crashed:
E/ActivityThread: App sent too much data in instance state, so it was ignored
android.os.TransactionTooLargeException: data parcel size 713856 bytes
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:615)
at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6044)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
But on compile/targetSdkVersion = 24 we have real RuntimeException crash in this case:
java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 713860 bytes
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3737)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6044)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
Caused by: android.os.TransactionTooLargeException: data parcel size 713860 bytes
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:615)
at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6044)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
Moreover, looks like on compile/targetSdkVersion = 23 we have only internal warning about large size of saved state, but nothing is crashed:
E/ActivityThread: App sent too much data in instance state, so it was ignored
android.os.TransactionTooLargeException: data parcel size 713856 bytes
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:615)
at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6044)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
But on compile/targetSdkVersion = 24 we have real RuntimeException crash in this case:
java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 713860 bytes
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3737)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6044)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
Caused by: android.os.TransactionTooLargeException: data parcel size 713860 bytes
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:615)
at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6044)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
p....@catenacyber.fr <p....@catenacyber.fr> #8
[Comment deleted]
mr...@google.com <mr...@google.com> #9
[Comment deleted]
pi...@gmail.com <pi...@gmail.com> #10
Observe same issue with Nexus 9 and Nexus 5X running build number NPD90G, during Activity.onSaveInstanceState(), with reported parcel size as low as ~600KB.
Other devices running Android N or 7 also suffer same issue, please see attached screenshot for device statistics.
Other devices running Android N or 7 also suffer same issue, please see attached screenshot for device statistics.
pi...@gmail.com <pi...@gmail.com> #11
By the way: this was mentioned as a behavior change for Android N: https://developer.android.com/preview/behavior-changes.html
Quote:
"Many platform APIs have now started checking for large payloads being sent across Binder transactions, and the system now rethrows TransactionTooLargeExceptions as RuntimeExceptions, instead of silently logging or suppressing them. One common example is storing too much data in Activity.onSaveInstanceState(), which causes ActivityThread.StopInfo to throw a RuntimeException when your app targets Android N."
Quote:
"Many platform APIs have now started checking for large payloads being sent across Binder transactions, and the system now rethrows TransactionTooLargeExceptions as RuntimeExceptions, instead of silently logging or suppressing them. One common example is storing too much data in Activity.onSaveInstanceState(), which causes ActivityThread.StopInfo to throw a RuntimeException when your app targets Android N."
p....@catenacyber.fr <p....@catenacyber.fr> #12
[Comment deleted]
ja...@google.com <ja...@google.com> #13
[Comment deleted]
p....@catenacyber.fr <p....@catenacyber.fr> #14
I don't know why but removing
fragmentTransaction.addToBackStack(null);
fixed the problem for me.
Hope can help someone else
fragmentTransaction.addToBackStack(null);
fixed the problem for me.
Hope can help someone else
ma...@gmail.com <ma...@gmail.com> #15
Since this is an app bug , we have reached out to the app developer.
ja...@google.com <ja...@google.com> #16
[Comment deleted]
ka...@gmail.com <ka...@gmail.com> #17
[Comment deleted]
Description
The reward for this fix being accepted upstream has been set at $300.
Original Report:
Hello graphviz team,
As part of our fuzzing efforts at Google, we have identified an issue affecting
graphviz (tested with revision * master 510f40d71448f7b8df18df1c2c3520787fcdadc5).
To reproduce, we are attaching a Dockerfile which compiles the project with
LLVM, taking advantage of the sanitizers that it offers. More information about
how to use the attached Dockerfile can be found here:
TL;DR instructions:
* `mkdir project`
* `cp Dockerfile /path/to/project`
* `docker build --no-cache /path/to/project`
* `docker run -it image_id_from_docker_build`
From another terminal, outside the container:
`docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer`
(reference:
And, back inside the container:
`/fuzzing/repro.sh /fuzzing/reproducer`
Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation. The sanitizer error that we
encountered is here:
ASAN:DEADLYSIGNAL
=================================================================
==11==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7fc440d68cc0 bp 0x7ffd25eda360 sp 0x7ffd25eda300 T0)
==11==The signal is caused by a READ memory access.
==11==Hint: address points to the zero page.
#0 0x7fc440d68cbf in rebuild_vlists /fuzzing/graphviz/lib/dotgen/conc.c:162:32
#1 0x7fc440d6935c in rebuild_vlists /fuzzing/graphviz/lib/dotgen/conc.c:194:2
#2 0x7fc440d6707c in dot_concentrate /fuzzing/graphviz/lib/dotgen/conc.c:242:2
#3 0x7fc440d88943 in dot_position /fuzzing/graphviz/lib/dotgen/position.c:127:2
#4 0x7fc440d74a16 in dotLayout /fuzzing/graphviz/lib/dotgen/dotinit.c:326:9
#5 0x7fc440d74117 in doDot /fuzzing/graphviz/lib/dotgen/dotinit.c:463:2
#6 0x7fc440d74019 in dot_layout /fuzzing/graphviz/lib/dotgen/dotinit.c:509:22
#7 0x7fc441786ac3 in gvLayoutJobs /fuzzing/graphviz/lib/gvc/gvlayout.c:85:2
#8 0x7fc441797c43 in gvLayout /fuzzing/graphviz/lib/gvc/gvc.c:65:9
#9 0x51d62b in LLVMFuzzerTestOneInput /fuzzing/graphviz/./fuzzer.cc:13:18
#10 0x50f9cc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/graphviz/fuzzer+0x50f9cc)
#11 0x50f18e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) (/fuzzing/graphviz/fuzzer+0x50f18e)
#12 0x508fed in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/fuzzing/graphviz/fuzzer+0x508fed)
#13 0x50a4bf in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/graphviz/fuzzer+0x50a4bf)
#14 0x508e9c in main (/fuzzing/graphviz/fuzzer+0x508e9c)
#15 0x7fc43f7232b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#16 0x41e5a9 in _start (/fuzzing/graphviz/fuzzer+0x41e5a9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /fuzzing/graphviz/lib/dotgen/conc.c:162:32 in rebuild_vlists
==11==ABORTING
We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.
Once you have reproduced the issue, we'd appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the report
to "Google Autofuzz project".
We are also pleased to inform you that your project is eligible for inclusion to
the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options.
Don't hesitate to let us know if you have any questions!
Google AutoFuzz Team