Philipp Hofmann

Maybe this is because our logic in `sentrycrashdl_getBinaryImage`, which the `SentryDebugImageProvider` uses, has some problems, as you pointed out in https://github.com/getsentry/sentry-cocoa/issues/1892#issuecomment-1171990378?

The benefit of this fix is that the running code doesn't pollute the logs. If you pass in a wrong DSN, the SDK should only print one error message that...

`SentrySerialization.dataWithEnvelope` does a couple of calls to `NSMakeRange` that can easily lead to a crash if not handled carefully. https://github.com/getsentry/sentry-cocoa/blob/464117d76c03363a8a5699b3edd07c57398c9518/Sources/Sentry/SentrySerialization.m#L95 https://github.com/getsentry/sentry-cocoa/pull/4281 could fix one part of the problem, but we...

I don't have much to add from the Mobile perspective because, on Mobile, we encourage our users to call the static APIs `Sentry.captureException`, etc., and hardly any users interact with...

After talking to more mobile folks, we don't see a problem with moving forward with this, but we don't see a need to change that cause it doesn't cause any...

@matthewreimer, which Xcode version are you using?

Using `dladdr` is way faster than using our own version of `dladdr`, which is async safe and we only need when the application is crashes. This could blow up easily...

At the moment, I can think of two ways to achieve this. ## Option A In case of a fatal crash, we could call into ObjC to finish the ongoing...

@aellett, we haven't revisited this lately. It's still on our backlog. This is different because you can still call Java code when your application terminates due to a crash on...

@aellett, can you please describe your use case for this feature a bit? Could it be that fixing https://github.com/getsentry/sentry-cocoa/issues/4375 solves your underlying problem? As this feature would bend the rules...