Event Processing Error for Exception Subcode with UInt64

[lhunath]

Steps to Reproduce

Send an event with exception.values.0.mechanism.meta.mach_exception.subcode = 9223372036854775816, which slightly overflows an unsigned Int64.

Expected Result

No processing errors.

Actual Result

https://hubstaff.sentry.io/issues/6206119990/events/e4d7eb43c2694b2294c5e0b12bab43ed/

The issue on Sentry displays a processing error and turns the 9223372036854775816 into a negative number -9223372036854776000, even though 9223372036854775816 is an unsigned Int64, but it overflows a signed Int64.

[philipphofmann]

I have no idea what's causing this, and it's the first time I see this. For internal reference, we read the subcode here into the crashContext and mask it with MACH_ERROR_CODE_MASK

https://github.com/getsentry/sentry-cocoa/blob/91ceb3f24c186891f16c2497cae1443741413089/Sources/SentryCrash/Recording/Monitors/SentryCrashMonitor_MachException.c#L376-L377

https://github.com/getsentry/sentry-cocoa/blob/91ceb3f24c186891f16c2497cae1443741413089/Sources/SentryCrash/Recording/Monitors/SentryCrashMonitor_MachException.c#L51-L55

The code is of type mach_exception_data_type_t, which is int64_t.

https://github.com/getsentry/sentry-cocoa/blob/91ceb3f24c186891f16c2497cae1443741413089/Sources/SentryCrash/Recording/Monitors/SentryCrashMonitor_MachException.c#L90-L95

So the subcode can actually be negative. If I'm not mistaken, a negative value in mach_exception_data_type_t can occur when it actually represents memory addresses or custom error codes. @supervacuus, as your native knowledge is more extensive than mine, do you know what could cause this? If this is a valid subcode, we need to adapt the backend to remove the warning.

[supervacuus]

The meaning of the subcode depends on the code. In contrast to code, it is not abstract and can contain machine-specifics like status-register contents, virtual memory addresses, stack-pointers, etc. And, of course, that could mean that the resulting value, if interpreted as a signed integer, is negative.

The problem is that the value -9223372036854776000 overflows int64_t (the smallest int64_t is -9223372036854775808). This means it is not representable if you store it in an int64_t, and thus, it is unclear how that value could even be sent from a client SDK (it is also a signed overflow, which means it is undefined behavior in the client).

Understanding how that value could have materialized along the entire processing pipeline first might get you closer to a suitable answer.

[philipphofmann]

@supervacuus, the SDK writes both the subcode and code as UInts here

https://github.com/getsentry/sentry-cocoa/blob/43815bc22bd3b68321f2374d60f2c5b7c763d1e8/Sources/SentryCrash/Recording/SentryCrashReport.c#L1257-L1262

When the subcode, for example, is negative, casting it to an UInt could cause these overflows. Would it make sense to change the code an Int when writing the crash report make sense? I drafted this here. I changed both code and subcode, but maybe it makes sense to only change the subcode to Int instead of UInt: https://github.com/getsentry/sentry-cocoa/compare/fix/allow-negative-mach-code-subcode?expand=1

[supervacuus]

The thing is, even if you cast here and the resulting unsigned integer is 9223372036854776000 (meaning it came in as -9223372036854775616), why is it rendered/interpreted as a negative number in the backend?

I drafted this here. I changed both code and subcode, but maybe it makes sense to only change the subcode to Int instead of UInt: https://github.com/getsentry/sentry-cocoa/compare/fix/allow-negative-mach-code-subcode?expand=1

IMHO, it is generally fair to keep the type used in the system as long as possible and only let the UI decide how to render things depending on the code. For instance, if the subcode is an address, you don't care whether the value is a decimal signed or unsigned type; you probably want to see an unsigned hex representation of the value. If it is the content of a status register, you should know about the bit groups it contains.

If the UI doesn't do rendering specific to the code/subcode pair, then a user can still recover the information themselves from either a signed or unsigned int, but it shouldn't be an unsigned int that gets a minus prepended.

[philipphofmann]

Ah, now I get it. The client actually sets the subcode correctly. The event payload contains 9223372036854775816, which overflows int64_t. Actually, the error message is wrong. I'm transferring this to the main repo.

FYI, @lhunath, I modified your description so the folks on the main repo know how to fix it.

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-issues for triage ⏲️

[malwilley]

I believe this error message is coming from Relay, so I'll transfer to that repo.