Why is crashpad recording all these 0 values?

[alecazam]

Is Backtrace supposed to be filling these out, is there something we're not setting. These are really not fun to sort through when intermixed with real attributes that we've recorded. I'm on the latest build of 0.1.0, and so I'd hoped these would go away after we updated to latest.

"device.model": null, "_request.truncated": null, "application.session": "00000000-0000-0000-0000-000000000000", "_compressed": 0, "lang.version": null, "lang.name": null, "gc.heap.used": 0, "gc.heap.total": 0, "cpu.process.blocked": 0, "cpu.process.running": 0, "cpu.process.count": 0, "cpu.brand": null, "cpu.arch": null, "cpu.boottime": 0, "cpu.context": 0, "cpu.softirq": 0, "cpu.irq": 0, "cpu.iowait": 0, "cpu.idle": 0, "cpu.kernel": 0, "cpu.nice": 0, "cpu.user": 0, "system.memory.vmalloc.chunk": 0, "system.memory.vmalloc.used": 0, "system.memory.vmalloc.total": 0, "system.memory.slab": 0, "system.memory.writeback": 0, "system.memory.dirty": 0, "system.memory.swap.free": 0, "system.memory.swap.total": 0, "system.memory.inactive": 0, "system.memory.active": 0, "system.memory.swap.cached": 0, "system.memory.cached": 0, "system.memory.buffers": 0, "system.memory.free": 0, "system.memory.total": 0, "sched.cs.involuntary": 0, "sched.cs.voluntary": 0, "vm.swap.size": 0, "vm.pte.size": 0, "vm.shared.size": 0, "vm.data.size": 0, "vm.stack.size": 0, "vm.rss.size": 0, "vm.rss.peak": 0, "vm.locked.size": 0, "vm.vma.size": 0, "vm.vma.peak": 0, "descriptor.count": 0, "uname.release": null, "_missing_symbol": 0, "_delete_reason_audit": null, "_delete_reason": null, "_deleted": 0

[alecazam]

I guess I'd thought that Backtrace/crashpad would at least record a few fields on it's own, and not require us to supply all useful data.

[konraddysput]

Hi @alecazam those are attributes populated by Backtrace by default. You can use them by default in the query builder and more (see more about Backtrace attributes). By default crashpad might not populate them Automatically but rest of our SDKs collect it.

[alecazam]

I still don’t understand the point. How can you base a query on all 0 values. Why bother to record these? We already have attributes now via the simple_annotations(), but I don’t want all these invalid values recorded.

[konraddysput]

Those are default attributes in Backtrace. Each attribute you collect via crashpad, will be stored in Backtrace, however, if you want to start making queries in the web UI, you need to index the attribute. By default, all attributes you add are not indexed, because otherwise, it will consume a lot of your storage. If you don't add an attribute and you have it indexed, the value of the attribute is automatically populated by the attribute default (like 0). Some of the attributes are populated by default by all our integrations, so this is why you see zeros there, because the attribute is added by default in the system, however, you're not adding it in crashpad.

This is what you have by default in your Backtrace instance.

[konraddysput]

For more information please visit: https://docs.saucelabs.com/error-reporting/project-setup/attributes/

[alecazam]

When I hover over any of these attributes in Backtrace, it says they are all non-indexed. So they shouldn't be getting recorded or 0-ed and null-ed out.

I still don't know from your response how to suppress them. Do I need to build a custom crashpad, or do I need to suppress these in the attribute interface described above. What I don't understand is why these are added by default. They serve no useful purpose, and are just noise in our useful data.

I don't see any of these fields in the minidump json file that I download from Attachments. It has just the attributes that we specified, so Backtrace is adding these into our data even though they have no utility. How do we suppress that.

[konraddysput]

When I hover over any of these attributes in Backtrace, it says they are all non-indexed. So they shouldn't be getting recorded or 0-ed and null-ed out.

Because they're indexed by default. We don't need to populate them, because they're on default attribute list.

I still don't know from your response how to suppress them.

You need to populate them. We do not have an option to disable/remove them. I added a note to our product backlog to try to hide them in specific cases, based on your post here.

What I don't understand is why these are added by default.

Our SDKs populate them by default and based on our experience with customers, there are a lot of useful use cases for them to use, like for example: detecting startup crashes, memory issues, etc.

They serve no useful purpose and are just noise in our useful data.

They're being used in the query builder. There is a purpose to have them but not in your specific case if you don't populate them.

With that being said: the behavior right now is those are auto-indexed attributes, that are being used by default by most of our users who use our SDKs. Crashpad is one of the SDK we fork and we maintain here. It's not "ours" SDK and we use it in multiple other places, like for example in game engines, mobile apps etc, where we do populate those values.

I noted a product request from you and hope it clarifies all your questions. These are great questions, but not necessarily about crashpad. Please do use support@backtrace.io for questions about Backtrace - that's a much better channel for this.

[alecazam]

I'm not going to populate 40 variables that we don't care about. We will record physical and gpu memory totals in our own attributes. Also the simple_annotations is limited to 64 entries, and that's all that backtrace supports. So we're not going to waste that on these fields.

So from what I read above, the Windows build doesn't populate any of this info. Maybe Unity does, but we are a custom rendering engine. We can't suppress these with a custom build of crashpad, can override them with simple_annotation(), and can't populate or suppress these values in the Backtrace UI currently.

Also to populate any of this, I need to know what these values mean. I'm assuming some are in bytes. But I don't see any of that in the attribute docs posted.

[konraddysput]

If you're comming from the game engine industry, you can take a look into attribute descriptions for Unity; https://support.backtrace.io/hc/en-us/articles/360058376512-Unity-Attribute-List also, when you try to use the attribute in a query builder, you should get a quick description on what the attribute stores. I know this advice doesn't solve your issue, but just in case it's helpful when you use the system

[alecazam]

That page is what I need. I know what all these values vaguely mean, but it's unclear from reading a key if it's Kilobytes, bytes, etc. Thank you. We still won't be recording these fields, so they just make it difficult to read the ones that we do record.