Closed Bug 1519802 Opened 4 years ago Closed 4 years ago

The "Build Architecture Info" field always ends with the number of processors

Categories

(Socorro :: Webapp, task, P2)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gsvelto, Assigned: willkg)

Details

Attachments

(1 file)

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.

Summary: The "Build Architecture Info" field is not populated when the corresponding CPU information is empty → The "Build Architecture Info" field always ends with the number of processors

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.

No longer blocks: aarch64-crash-reporting

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.

Assignee: nobody → willkg
Status: NEW → ASSIGNED
Priority: -- → P2
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
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.