Skip to content

flutter_gallery_ios32__transition_perf test consistently failing with VMServiceFlutterDriver error #57756

Closed

Description

@iskakaushik

Full stack trace for the error is at: https://gist.github.com/iskakaushik/fef32af4d559ee0f5450ec65f07f6a16

2020-05-18T14:28:09.819332: stderr: VMServiceFlutterDriver: Instance of '_WebSocketImpl' is closed with an unexpected code 1005
2020-05-18T14:28:09.819559: stderr: VMServiceFlutterDriver: Instance of '_WebSocketImpl' is closed with an unexpected code 1005

This seems to be happening on slower/older devices, i.e, iPhone 4S in our dashboard and @jason-simmons' Moto G4. (also referenced in #57586 (comment))

These tests started to become consistently red from consistently green starting: #57402

Activity

  1. added this to the milestone on May 21, 2020
  2. added
    a: tests"flutter test", flutter_test, or one of our tests
    engineflutter/engine related. See also e: labels.
    c: crashStack traces logged to the console
    c: contributor-productivityTeam-specific productivity, code health, technical debt.
    c: regressionIt was better in the past than it is now
    on May 21, 2020
  3. jason-simmons commented on May 26, 2020

    @jason-simmons
    Member

    I tried looking at some Instance of '_WebSocketImpl' is closed with an unexpected code 1005 failures that I saw while running this benchmark on a Linux/Android setup.

    The socket closure happened while the driver script was invoking getVMTimeline. Downloading the timeline data was taking over 30 seconds.

    On the device side, the VM service in the app process was successfully generating the timeline JSON and writing it to the socket as expected. But it looked like the app process was being terminated by a SIGKILL before the driver script received all the data. I don't know who is sending the SIGKILL.

  4. zanderso commented on May 27, 2020

    @zanderso
    Member

    @jason-simmons Could the app be getting sent SIGKILL by the OS for some perceived misbehavior?

  5. added
    P2Important issues not at the top of the work list
    on May 29, 2020
  6. zanderso commented on Jun 1, 2020

    @zanderso
    Member

    It looks like the tree is closed on this flake again. I noted in chat that it became noticeably flakier after the engine roll here: 68073a0. Team velocity is affected by this issue, so I am bumping the priority to P1 and assigning @jason-simmons to investigate further.

    /cc @godofredoc in case he has some hints about where the SIGKILL might be coming from.

    @jason-simmons please assign back to me if you won't be able to get to this sometime this week. Thanks!

    (@kf6gpe sorry if I'm using the new priorities wrong!)

  7. added and removed
    P2Important issues not at the top of the work list
    on Jun 1, 2020
  8. zanderso commented on Jun 1, 2020

    @zanderso
    Member

    Ah, sorry, it's new_gallery__transition_perf whose failure is currently closing the tree on this issue, which I guess we can possibly conclude is affecting multiple benchmarks.

  9. jonahwilliams commented on Jun 1, 2020

    @jonahwilliams
    Contributor

    I'm going to make an educated guess that Android itself is sending the SIGKILL, it has similar behavior if you attempt to send "a lot" of data over the VM Service or even through print. In the Flutter framework, the print wrapper throttles output for this reason: https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/foundation/print.dart#L43

    If this is the case, the solution is to add pagination to the timeline request somehow and download in chunks.

  10. jonahwilliams commented on Jun 1, 2020

    @jonahwilliams
    Contributor

    Either that, or some component in the Dart start is being overwhelmed and doing something similar

  11. zanderso commented on Jun 1, 2020

    @zanderso
    Member

    @bkonyi Do you know where a good place would be to experiment with throttling the VM's response to a getVMTimeline VM service request?

  12. jason-simmons commented on Jun 2, 2020

    @jason-simmons
    Member

    Looked some more at the new_gallery__transition_perf benchmark. I think the app process on the device is being killed because it is reaching a memory limit. The payload of the getVMTimeline service RPC response is 110MB, and the app process' VmSize can approach 2GB while serializing the response.

    The timeline chunking patch landed by @jonahwilliams reduces peak memory consumption and appears to make the benchmark much more likely to run to completion.

  13. zanderso commented on Jun 2, 2020

    @zanderso
    Member

    @jason-simmons thanks for digging deeper, and thanks @jonahwilliams for the fix. Since neither flutter_gallery_ios32__transition_perf nor new_gallery__transition_perf has flaked since Jonah's change, I think we should leave the chunking in place, and remove the flaky mark from flutter_gallery_ios32__transition_perf.

  14. github-actions commented on Aug 13, 2021

    @github-actions

    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.

  15. locked as resolved and limited conversation to collaborators on Aug 13, 2021
  16. added
    P0Critical issues such as a build break or regression
    and removed on Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P0Critical issues such as a build break or regressiona: tests"flutter test", flutter_test, or one of our testsc: contributor-productivityTeam-specific productivity, code health, technical debt.c: crashStack traces logged to the consolec: flakeTests that sometimes, but not always, incorrectly passc: regressionIt was better in the past than it is nowengineflutter/engine related. See also e: labels.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions