-
-
Notifications
You must be signed in to change notification settings - Fork 376
Open
Description
Platform
macOS
Environment
Production
Installed
Swift Package Manager
Version
8.56.2
Xcode Version
26.2
Did it work on previous versions?
No response
Steps to Reproduce
We've noticed on several reports that the "Application Specific Information" section of the crashes seem to contain random contents of memory, rather than actual application crash data:
- often see partial/truncated stack information (that doesn't seem to relate to the actual crash)
- in one case it contained a portion of an email message (not something we would include in reports), or other random data; we feel this presents a risk of privacy/security since this random memory data can potentially contain PII
- in the examples provided, a common cause of the crash is a stack overflow due to excessive recursion, but may not always be the cause in all cases we've seen this random data
- to us this looks like bad pointer arithmetic
- there's no specific steps to "reproduce" this that we can determine
- given the unpredictable nature of the random data that may be present, we don't think we could reliably do any scrubbing of that information when submitting the report from the application.
- see the attached reports for examples/comparison
Our Sentry config options are:
options.enableAppHangTracking = NO;
options.enableSwizzling = NO;
options.enableCaptureFailedRequests = NO;
options.experimental.enableUnhandledCPPExceptionsV2 = YES;
Other notes:
The examples include reports retrieved from Sentry, as well as the same crashes retrieved from the user's machine (when available). We noted the reported thread numbers were off-by-one, as are some of the binary image addresses. The reports were correlated by launch time and other values common in each report source.
Expected Result
Crash reports retrieved from the user's machine:
Actual Result
The same crashes retrieved from Sentry:
Sentry retrieved crashes.zip
Are you willing to submit a PR?
No response