memory-infra of chrome://tracing for a remote Android device doesn't work |
|||
Issue descriptionChrome Version: ToT OS: Host: Ubuntu Linux x64, Guest: Android Nexus 4 What steps will reproduce the problem? (1) Connect the device (Android) (2) Open a tab with a URL like https://google.com/ (3) Open chrome://inspect?tracing and open chrome://tracing for the remote device (4) Try to record with checking memory-infra What is the expected result? Obtained memory infra dumps What happens instead? Nothing Screen shot: https://drive.google.com/file/d/0BwW8PrCcts4WaS1ERUx6b2N6Ums/view?usp=sharing Please use labels and text to provide additional information. * After pressing 'Record' button in the dialog, the progress was not changed from 0%. It looks like most of the other data were not recorded. * The attached JSON file is the dump result when trying to record blink/cc/netlog/toplevel/v8 and memory-infra. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Jul 11 2017
> (2) Open a tab with a URL like https://google.com/ This is in the guest device. > (3) Open chrome://inspect?tracing and open chrome://tracing for the remote device > (4) Try to record with checking memory-infra These are in the host device.
,
Jul 11 2017
I picked a ChromePublic.apk off the top of the waterfall[1]. Then I tried repoing with both 59.0.3071.115 (stable) and 61.0.3141.7 (dev) as the host. The problem reproduced on 59.0.3071.115 but not on 61.0.3141.7. Perhaps we changed how memory-infra is triggered? hajimehoshi@: Which version was the host Chrome? If it was not very recent could you try with a very recent build for the host, thanks! primiano@: Maybe something to do with Erik's changes to the trace config? https://bugs.chromium.org/p/chromium/issues/detail?id=735124 [1]: https://build.chromium.org/p/chromium.linux/builders/Android%20Builder/builds/85126
,
Jul 11 2017
,
Jul 12 2017
Thanks, > hajimehoshi@: Which version was the host Chrome? If it was not very recent could you try with a very recent build for the host, thanks! b1601a7ae547960927ebc20de9776dc0c2e779e3 (Sun Jul 9 21:44:42 2017 -0700) Version 61.0.3154.0 (Developer Build) (64-bit) Hmm, this should be fixed?
,
Jul 12 2017
Sorry but the Chrome (at comment #5) is the guest, and the host is Version '59.0.3071.115 (Official Build) (64-bit)'. Does the host Chrome version matter in this issue? Thanks.
,
Jul 12 2017
> The problem reproduced on 59.0.3071.115 but not on 61.0.3141.7. That is the range when Erik fixed that: $ git log 59.0.3071.115..61.0.3141.7 --author=erikchen --pretty=oneline -- \*mem\* c72902d0a30ee1fc71e7890d14c9ca79c3d387b3 Change memory dumps to not use periodic dumps by default. ... 8b0b2a16a1e141102620e7d173271197cd6b7f3d Revert of Change memory dumps to not use periodic dumps by default. (patchset #3 id:40001 of https://codereview.chromium.org/2912483002/ ) ... 0529413d84c06f3720bf4a56b28bb2c7358cefd1 Change memory dumps to not use periodic dumps by default. > Does the host Chrome version matter in this issue? Thanks. Yes, I think because of this: https://codereview.chromium.org/2948023002 Which rolled into 247215d39e070e9e9d9ff4dc58a6f37682a5d125 which is between 59 and 61. Mystery solved. Thanks hjd@ for checking this.
,
Jul 13 2017
Sure, thank you very much! |
|||
►
Sign in to add a comment |
|||
Comment 1 by primiano@chromium.org
, Jul 11 2017