Stack traces seem to incorrectly end at function _sigtramp - leads to incorrect grouping

[kpujjigit]

Description

I've noticed that there are a lot of events (native crashes) being grouped together into one issue, specifically on MacOS. Despite having different causes (from their logs and the panic message added to some of them), they are grouped since their stack traces seem to incorrectly end at the function _sigtramp.

One delta I've observed is the number of dynamic libraries applied for the events stopping at _sigtramp (Screenshot1) and events that do not (screenshot2) - I see an extra dylib for the latter, do you happen to have context on this?

When does the problem happen

• [ ] During build
• [ ] During run-time
• [x] When capturing a hard crash

Environment

• OS: macOS
• Compiler: [e.g. MSVC 19]
• CMake version and config: [e.g. 3.17.2, SENTRY_BACKEND=inproc]

Steps To Reproduce

Log output

[markushi]

Hey @kpujjigit, thanks for reaching out! Could you share a few more details with us:

• OS version of the system where _sigtramp occurs
• If possible, an example stack trace
• Is there any specific reason you're using the inproc backend instead of crashpad?

[getsantry[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you remove the label Waiting for: Community, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[kpujjigit]

Hey @kpujjigit, thanks for reaching out! Could you share a few more details with us:

• OS version of the system where _sigtramp occurs
• If possible, an example stack trace
• Is there any specific reason you're using the inproc backend instead of crashpad?

Shared the above internally with @loewenheim :)

[Dav1dde]

Unfortunately this is a limitation of the implementation and we cannot improve this behaviour without significant efforts.