The "Build Architecture Info" field always ends with the number of processors
Categories
(Socorro :: Webapp, task, P2)
Tracking
(Not tracked)
People
(Reporter: gsvelto, Assigned: willkg)
Details
Attachments
(1 file)
(deleted),
text/x-github-pull-request
|
Details |
When processing Windows AArch64 crash reports breakpad's CPU field information is empty. Running 'stackwalker --pipe' on a dump [1] yields a CPU information line that looks like this:
CPU|0x000c||8
The 0x000c is the vendor field (Qualcomm in this case) and the following empty field is what corresponds to the CPU info field (system_info.cpu_info in the JSON output) and the last is the number of processors.
When looking at the crash report on crash-stats the "Build architecture info" field in the "Details" tab should be empty but it contains the "|8" string instead. So some component is misinterpreting the empty field and putting the end of the string with the number of CPUs in its place.
[1] https://crash-stats.mozilla.com/report/index/805e5528-4997-4569-adf9-3ecbc0190113
Reporter | ||
Comment 1•6 years ago
|
||
This also happens on Fennec crash reports, see this one for example:
https://crash-stats.mozilla.com/report/index/65a147b8-0ed9-4e4f-9b48-4d25d0190113
(In reply to Gabriele Svelto [:gsvelto] from comment #0)
So some component is misinterpreting the empty field and
putting the end of the string with the number of CPUs in its place.
I'm not sure I understand the "misinterpreting" part -- it looks to me like everything is happening normally except that cpu_info is empty.
That seems to be allowed... https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/toolkit/crashreporter/google-breakpad/src/processor/stackwalk_common.cc#881
...because only Intel builds write something there: https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/toolkit/crashreporter/google-breakpad/src/processor/minidump_processor.cc#494-495,509
Also, the hex code happens because we don't have a case for MD_CPU_ARCHITECTURE_ARM64: (only "ARM64_OLD", whatever that is): https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/toolkit/crashreporter/google-breakpad/src/processor/minidump_processor.cc#538,552
Reporter | ||
Comment 3•6 years ago
|
||
(In reply to David Major [:dmajor] from comment #2)
I'm not sure I understand the "misinterpreting" part -- it looks to me like everything is happening normally except that cpu_info is empty.
That seems to be allowed... https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/toolkit/crashreporter/google-breakpad/src/processor/stackwalk_common.cc#881
...because only Intel builds write something there: https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/toolkit/crashreporter/google-breakpad/src/processor/minidump_processor.cc#494-495,509
Also, the hex code happens because we don't have a case for MD_CPU_ARCHITECTURE_ARM64: (only "ARM64_OLD", whatever that is): https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/toolkit/crashreporter/google-breakpad/src/processor/minidump_processor.cc#538,552
The problem is not about the vendor field (I've just filed bug 1519845 for that) it's what Socorro calls "Build Architecture Info" in the crash-stats interface. It should only contain the x86-specific processor information but it always ends with a vertical bar followed by the number of processors. I'm actually changing the name of this bug to reflect that. So on x86 it's:
family 6 model 78 stepping 3 | <number of processors>
And on other processors just:
| <number of processors>
Which I find confusing.
Reporter | ||
Comment 5•6 years ago
|
||
Just the contents of the "system_info.cpu_info" field in the dump which currently corresponds to the x86-specific family-model-stepping string w/o the trailing '|' and number of processors. Once we'll have an ARM64-specific description of the processor in breakpad it'll end up there too.
Also this doesn't need to block bug 1513284 since it's not AArch64-specific.
The number of processors is occasionally useful in crash reports. Do you intend to preserve it somewhere?
Reporter | ||
Comment 7•6 years ago
|
||
(In reply to David Major [:dmajor] from comment #6)
The number of processors is occasionally useful in crash reports. Do you intend to preserve it somewhere?
Yes, we might want to treat it separately especially because it's not really visible right now and it's not searchable. I only accidentally realized that it appeared in that field, the field description doesn't mention it at all. It's always present in the raw dump (under system_info.cpu_count) and that's where we should be taking it from and it's also set as the NumberOfProcessors [1] annotation, but only in Windows plugin processes IIRC. We could probably get rid of that since it's redundant.
Assignee | ||
Comment 8•6 years ago
|
||
There's another bug about how this is a confusing key/val in the report view. I'm game for ditching it and replacing it with separated cpu_info and cpu_count fields. I think that'll work and be backwards compatible with processed crashes and won't affect searching.
Build Architecture :
CPU Info :
CPU Count :
Is that more helpful and less confusing?
As an aside, bug #1305956 seems related to this one.
Reporter | ||
Comment 9•6 years ago
|
||
(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #8)
There's another bug about how this is a confusing key/val in the report view. I'm game for ditching it and replacing it with separated cpu_info and cpu_count fields. I think that'll work and be backwards compatible with processed crashes and won't affect searching.
Build Architecture : CPU Info : CPU Count :
Is that more helpful and less confusing?
Yes, that would be great, especially if the CPU count field would also be searchable and could be filtered.
As an aside, bug #1305956 seems related to this one.
Yeah.
Assignee | ||
Comment 10•6 years ago
|
||
I think CPU Count is already a separate search field. Is that not working for you?
I'll try to get to this soon.
Assignee | ||
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
Commits pushed to master at https://github.com/mozilla-services/socorro https://github.com/mozilla-services/socorro/commit/110958c1dfd013ab85bc46123371b534dd62f044 fix bug 1519802, bug 1305956: fix cpu_info, cpu_arch/cpu_name, and cpu_count Previously, "cpu_info" was composed of "cpu_info" and "cpu_count" from the system_info in the json_dump. Socorro indexed this and also cpu_count so they were both available for searching. The report view showed the cpu_info value. But this is confusing in a few scenarios and there doesn't seem to be a good reason to have a contrived value like this. This changes it so cpu_info is just the cpu_info value from json_dump.system_info. It also adds cpu_count to the crash report and the report view. This also changes the name from "Build Architecture Info" (which doesn't make sense) to "CPU Info". While doing that, I removed two deprecated items from Elasticsearch fields and also moved the whole cpu_name -> cpu_arch deprecation another step. https://github.com/mozilla-services/socorro/commit/22029792f117305fe41b0be6e27b1551fbf688c6 Merge pull request #4779 from willkg/1519802-cpu-info fix bug 1519802, 1305956: fix cpu_info, cpu_arch/cpu_name, and cpu_count
Updated•6 years ago
|
Assignee | ||
Comment 13•6 years ago
|
||
Reopening this because it needs testing on stage after a week or so of being out there.
Assignee | ||
Comment 14•6 years ago
|
||
Everything looked good on stage. I deployed this to prod just now. Marking as FIXED.
Description
•