captureException captures the wrong stack trace

[remvst]

Platform

Apple

Installed

CocoaPods

Version

0.9.0

Steps to Reproduce

1. create a Throwable at site A
2. call captureException() from site B

Expected Result

Exception on the dashboard should include the stack trace at the time the exception was instantiated (i.e. site A)

Actual Result

Exception on the dashboard includes the stack trace at the time captureException() is called (i.e. site B)

Notice how the top of the stack includes Sentry. Breadcrumbs seem accurate though.

Works as expected on Android, but not on iOS.

[buenaflor]

hi, is this stacktrace symbolicated stacktrace?

[remvst]

hi, is this stacktrace symbolicated stacktrace?

I believe so? The stack trace is perfectly readable (function names, line numbers...), it's just not the correct one

[buenaflor]

@remvst I'm asking since it's also possible this is coming from a non-obfuscated build e.g debug vs release build

Do you still have access to the event? you could send that over to [email protected] so I can have a closer look

[buenaflor]

@remvst I looked at your event, what's odd is that your stacktrace is not 'unsymbolicated'. how did you compile the app? usually release builds are compiled with optimizations etc... so the raw stacktrace would only contain memory addresses instead of function names which is not the case for you here.

I am not sure if that would fix the issue but the stacktrace would probably look different

[remvst]

@remvst I looked at your event, what's odd is that your stacktrace is not 'unsymbolicated'. how did you compile the app? usually release builds are compiled with optimizations etc... so the raw stacktrace would only contain memory addresses instead of function names which is not the case for you here.

I am not sure if that would fix the issue but the stacktrace would probably look different

It was compiled as a release build, which is on the App Store (the event I sent you was from an actual user). We do send the dsym to Sentry using Fastlane:

  private_lane :upload_symbols do
    dsym_path = lane_context[SharedValues::DSYM_OUTPUT_PATH]

    sentry_debug_files_upload(
      auth_token: ENV["SENTRY_AUTH_TOKEN"],
      org_slug: 'XXX',
      project_slug: 'XXX',
      path: dsym_path,
    )
  end

I'm honestly not an expert at these things, so I'm hoping that answers your question?

Again, all other prod traces work fine for us, we're able to debug crashes (unhandled errors) fine using the stack trace, but manually captured exceptions (handled errors) have incorrect stack traces, so we have to do a bit of guessing work and use breadcrumbs to figure out what causes them.

[buenaflor]

Okay thanks for the detailed info, I'll dig deeper into this

[Legion2]

We are facing the same issue, I can see the stack trace of our exception logger which calls captureException but cannot see the kotlin stack trace where the exception come from. Because the exception logger is a very generic component basically all out exceptions are processed by it, so all stack traces now only show this generic stack trace and we don't get any useful data from the actual exception besides the exception message.