Repository navigation
feat(errortracking): attach the tombstone text to native crash events - #868
turnipdabeets wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
PostHog Review · Standard · reviewed 8007fd0: 1 Should fix.
This is the only automatic review while this pull request is a draft. Comment @posthog review to review new changes sooner. Otherwise, a review of the new changes runs when you mark it ready for review.
posthog-android Compliance ReportDate: 2026-10-27 16:09:41 UTC ✅ All Tests Passed!46/46 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
|
🤖 Bot review: I’d fix the async MTE warning before release. For I wouldn’t block release on GWP-ASan/Scudo heap allocation/deallocation backtraces: |
6ec0288 to
89adf00
Compare
89adf00 to
f8d2d53
Compare
💡 Motivation and Context
This is the Android pair of PostHog/posthog-ios#957 and addresses PostHog/posthog#117880, which came from a customer support ticket. Native (NDK) crash events only carry the crashing thread's stack. Customers can't see the full report Android itself produces for a native crash, the debuggerd tombstone: every thread, the registers, the signal details.
The SDK already reads the tombstone on the next launch (
ApplicationExitInfo, Android 12+). It now renders it as text in debuggerd's own format, following AOSP'stombstone_proto_to_text.cpp, and attaches it as$exception_crash_report. That's the same property iOS sends.$exception_listand$debug_imagesdon't change, so symbolication and issue grouping work exactly as before.What's in the report:
What's left out, and why:
Size, which needs a decision from error tracking: a native crash event grows from about 70 KB to about 300 KB. A typical app has about 50 threads, and ART's frames are long. That's much more than iOS, about +10 KB.
beforeSend, which is why the coreposthogpackage changes too. If the event is over 900 KB, the SDK drops only the report, so the crash event is never lost.Also in this PR:
fault addr 0x0…like debuggerd. I deliberately didn't change the$exceptionvalue, which still saysSEGV_MAPERRinstead ofSEGV_MAPERR at 0x0, because changing it would regroup existing issues. That should be tracked separately.For error tracking (@PostHog/team-error-tracking):
💚 How did you test it?
spotlessCheckandapiCheckare clean, and there's no public API change.mainlanded in the same issue, with an identical$exception_list, so grouping is unchanged.📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
tombstone.proto. It's Android's own crash format, which Android developers already read in logcat and the Play Console.🤖 Generated with Claude Code