dSYM support

[vanschelven]

(tracker issue for dSYM support)

dSYM support — overview

Although events arrive in a standard JSON shape, we don’t get the same “code context” everywhere. This issue tracks the Apple side of that story.

1. On iOS and macOS, crashes carry addresses, not source. A dSYM is the Apple-specific debug symbols bundle that maps those addresses back to function, file, and line.

2. With dSYMs, stack traces become readable (your code and framework code show up with names and lines). Without them, you mostly see raw addresses.

3. dSYMs are produced at build time for each app/framework. They’re the Apple flavor of “mapping files” (same family as Java source bundles or JavaScript source maps, different format).

4. Showing source code context may also require separate access to sources; dSYMs enable the lookup, they don’t contain your code.

In short: this tracker is about making Apple crashes symbolicated and ready for code context by accepting and using dSYMs.

[zhuscat]

Hi, what is the current progress on this issue?

[vanschelven]

Hi, what is the current progress on this issue?

Thumbs-up wise I'm noticing it's quite popular, but I haven't put it on the front of the queue just yet... 😄

[vanschelven]

Request for data

(copy/pasta across similar issues)

I'm not a {THISLANG} programmer myself; To be able to scale further experimentation with implementing, here's a request for help:

1. Minimal repro (script or repo)
   E.g. as a GitHub repo or simple script: A small project that builds, triggers one test error, and shows exactly how you produced the artifact and event.

2. Artifact as uploaded
   The artifact exactly as your toolchain produced it for this case (whatever "artifact" means for {THISLANG}).

3. Event sample
   An actual event JSON that matches the artifact (i.e. an "incomplete" JSON that can be "made complete" using the artifact. (link to download json is at bottom of page in the event view).

4. Server-side view
   Set API_LOG_UNIMPLEMENTED_CALLS=True, run the upload again, and share the relevant log lines (see Setting for easier reverse-engineering of client API(s) #153 for how this works).

Parts of the wishlist above would already help, but the more the better.

Thanks very much in advance! Once I get my hands on some data, at the very least I can start with partial implementations of the API & doing some outside-bugsink experiments ("spikes") with getting it to work.