Increase the maximum stacktrace frame length

[brustolin]

Description

We are using 100 as a constant to create C arrays of Stacktrace frames.
The App hangs PR #1906 do this in a context that is not possible to allocate more memory.
We already received a few complaints that the Stacktrace is truncated and this may be the cause.

The first idea to improve this is to increase the value, with the obvious downside that we need to pre-allocate more memory every time we need to create the stack trace.

[philipphofmann]

@Swatinem and @armcknight , can you maybe help us here?

We allocate a struct with a maximum of 100 stack entries before suspending the threads. Here we are walking the stack cursor after suspending the threads. Do you have any recommendations on what to do when the stack has more than 100 entries? Now we ignore this, and the stacktrace would miss a few entries. We can't allocate memory either.

sentry-cocoa/Sources/Sentry/SentryThreadInspector.m

Lines 114 to 134 in 02de834

	sentrycrashmc_suspendEnvironment(&suspendedThreads, &numSuspendedThreads);
	// DANGER: Do not try to allocate memory in the heap or call Objective-C code in this
	// section Doing so when the threads are suspended may lead to deadlocks or crashes.
	SentryThreadInfo threadsInfos[numSuspendedThreads];
	for (int i = 0; i < numSuspendedThreads; i++) {
	if (suspendedThreads[i] != currentThread) {
	int numberOfEntries = getStackEntriesFromThread(suspendedThreads[i], context,
	threadsInfos[i].stackEntries, MAX_STACKTRACE_LENGTH);
	threadsInfos[i].stackLength = numberOfEntries;
	} else {
	// We can't use 'getStackEntriesFromThread' to retrieve stack frames from the
	// current thread. We are using the stackTraceBuilder to retrieve this information
	// later.
	threadsInfos[i].stackLength = 0;
	}
	threadsInfos[i].thread = suspendedThreads[i];
	}
	sentrycrashmc_resumeEnvironment(suspendedThreads, numSuspendedThreads);

[Swatinem]

I can’t think of anything, except increase the maximum length ;-)
We have the same limitations in native, and there we reserve space for 256 frames.

[philipphofmann]

Thanks, @Swatinem, for your reply. I thought so, but worth a shot. @brustolin, I think we could increase the value to 256 then.

[philipphofmann]

Do you do anything special when you exceed the maximum, like adding a special entry or making sure you cut from the bottom or top, or do you just ignore it, @Swatinem?

[Swatinem]

It just truncates at the bottom and stops unwinding when it reaches the limit.

[armcknight]

An alternative approach is to not keep the stack trace in memory, and write it out to disk (it can be deserialized back into memory outside of the thread-suspended sector). This is how Crashlytics does it: https://github.com/firebase/firebase-ios-sdk/blob/e2542c7932b0277bb4f5c6a9e0affa7076065481/Crashlytics/Crashlytics/Components/FIRCLSProcess.c#L389

They record a maximum of 600,000 frames on iOS: https://github.com/firebase/firebase-ios-sdk/blob/e2542c7932b0277bb4f5c6a9e0affa7076065481/Crashlytics/Crashlytics/Unwind/FIRCLSUnwind.c#L26-L34

This has an additional bonus that some data is preserved if for whatever reason we are terminated while doing this work. But, it comes at a cost of some additional implementation, and working with fds and write ain't that fun 🙃

[philipphofmann]

We also write stacktrace to disk when we crash, but this one we use when not crashing. So for App Hangs and in the future when calling captureMessage or captureError. Writing to disk when not crashing is definitely a tradeoff, which might not be worth it.

[brustolin]

Since this is only used for ANR, we are fine with increasing the maximum stack frame size to 256.