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

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

(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.

What do you propose for it to look like instead?

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?

(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.

[1] https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/toolkit/crashreporter/CrashAnnotations.yaml#519

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.

(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.

I think CPU Count is already a separate search field. Is that not working for you?

I'll try to get to this soon.

Reopening this because it needs testing on stage after a week or so of being out there.

Everything looked good on stage. I deployed this to prod just now. Marking as FIXED.