You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Flaky flutter drive test on Moto G4 with --trace-startup #59263
Very often when I run flutter drive for a test case in macrobenchmarks, with option --trace-startup (which is the case we run for devicelab. This issue is talking about running locally though.), the app crashes on the device with message "Unfortunately, macrobenchmarks has stopped." resulting in test fail. This only happens to Moto G4 but not Pixel 4.
The notice on host machine shows:
VMServiceFlutterDriver: Instance of '_WebSocketImpl' is closed with an unexpected code 1005
VMServiceFlutterDriver: Instance of '_WebSocketImpl' is closed with an unexpected code 1005
Any suggestion about what can check is appreciated!
It seems that this happens more often to tests that lasts for longer time and is computationally more intense.
For example cubic_bezier_perf__timeline_summary works fine, but cull_opacity_perf__timeline_summary fails.
We suspect it's because limited memory.
Recently there was a similar issue (#57756) where the application process on the device ran out of memory and was killed while running a benchmark. The peak memory usage occurred when the app was serializing the timeline events as JSON in response to a request by the benchmark script.
Retrieving the timeline in smaller chunks helped (verify that you have the patch: cd7dfd0). Beyond that, try reducing the duration of the benchmark.
We should also look at the trace event stream as it may have a lot of bloat. There is a mechanism in there to tokenize some common strings, but many of our events contain event-specific additional data and that data is reported as strings and those strings are not tokenized - they are strdup()'d, even if they are common strings like "0" and "1". This is a big waste as it adds a lot of toString overhead and then malloc fragmentation.
This bloat not only affects the data stored in the app while accumulating the events, but it also bloats the data sent over the connection when the events are dumped.
@CareF
Considering the age of this issue, could you confirm if this behavior occurs using latest version of framework ?
Would be good to know the status so we can update it accordingly.
I no longer have the device to test it. Sorry. I posted this issue when I was an intern member in the flutter team. I would assume this is most likely already solved.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
CareF commentedon Jun 11, 2020
Some logging if it will be helpful:
CareF commentedon Jun 11, 2020
It seems that this happens more often to tests that lasts for longer time and is computationally more intense.
For example
cubic_bezier_perf__timeline_summaryworks fine, butcull_opacity_perf__timeline_summaryfails.We suspect it's because limited memory.
jason-simmons commentedon Jun 12, 2020
Recently there was a similar issue (#57756) where the application process on the device ran out of memory and was killed while running a benchmark. The peak memory usage occurred when the app was serializing the timeline events as JSON in response to a request by the benchmark script.
Retrieving the timeline in smaller chunks helped (verify that you have the patch: cd7dfd0). Beyond that, try reducing the duration of the benchmark.
flar commentedon Jul 27, 2020
We should also look at the trace event stream as it may have a lot of bloat. There is a mechanism in there to tokenize some common strings, but many of our events contain event-specific additional data and that data is reported as strings and those strings are not tokenized - they are
strdup()'d, even if they are common strings like "0" and "1". This is a big waste as it adds a lot of toString overhead and then malloc fragmentation.This bloat not only affects the data stored in the app while accumulating the events, but it also bloats the data sent over the connection when the events are dumped.
darshankawar commentedon Oct 11, 2022
@CareF
Considering the age of this issue, could you confirm if this behavior occurs using latest version of framework ?
Would be good to know the status so we can update it accordingly.
CareF commentedon Oct 11, 2022
I no longer have the device to test it. Sorry. I posted this issue when I was an intern member in the flutter team. I would assume this is most likely already solved.
github-actions commentedon Oct 26, 2022
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.