Cannot correctly pprof perf data grabbed from Careena device. |
|||||||||
Issue descriptionI grabbed a perf.data from Careena device by running perf record -a -g and run pprof perf.data in my linux desktop with PPROF_BINARY_PATH pointing to debug symbol unzip from gs://chromeos-image-archive/grunt-release/R73-11515.0.0/debug.tgz Its flame is http://pprof.corp.google.com/user-profile?id=5aa6fb4e0de51734d95b77234f3b3d28&tab=flame However, the call stack is obviously wrong. I record a perf when the DUT is doing hangout consuming 100% CPU. It couldn't be something like KeyAuthorizationData that consumes most of the CPU cycle. It is an AMD Stoney Ridge device. I don't know if there's some trick to decrypt the perf data. p.s. I also try perf report --no-children -i perf_meet_100.data -g --sort=dso --symfs debug --vmlinux debug/boot/vmlinux --kallsyms debug/boot/System.map on linux desktop, the symbol is not aligned to what system was busy for.
,
Jan 3
,
Jan 4
,
Jan 4
Anyone knows who can help debug this?
,
Jan 4
Could you file a buganizer issue instead and attach / share the perf.data file and the debug symbols image?
,
Jan 4
Use pprof component in buganizer.
,
Jan 4
Dean. Please file a bugnizer issue. Thanks.
,
Jan 7
Filed as http://b/122432268. Close this one.
,
Jan 7
,
Jan 7
Per jcliang@ suggestion, I deployed nostrip locally built Chrome to Careena and the perf.data can be decrypted normally. PPROF_BINARY_PATH=~/chrome/src/out_grunt/Release pprof ../perf_careena_local_build.data The flame graph shows expected call stack when running Google Meet: https://pprof.corp.google.com/user-profile?id=3a27e8d539d492efba015cc7b17f9c07&tab=flame So right now, perf.data recorded under locally built Chrome can be decoded correctly. perf.data recorded under builtbot built Chrome cannot be decoded using symbol file found in chromeos-image-archive. This looks like debug symbol in ChromeOS image archive does not match its corresponding image. vapier@, do you think it is build flow related issue?
,
Jan 7
sorry, but there isn't enough information here. please describe & link to exact images/archives you're testing together. we've had no suggestions so far as to the debug information being out of sync. if they were, then crash reports would be corrupted too.
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.
,
Jan 18
(4 days ago)
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by vapier@chromium.org
, Jan 3