Fix SDK crash in encodeObject

[philipphofmann]

Description

The SDK sometimes crashes with. See also internal SDK crashes for reference. This is our most frequent SDK crash in our latest stable release 8.36.0.

Exception Type: EXC_CRASH (SIGABRT)

Thread 0 Crashed:
0   libsystem_kernel.dylib          0x1e5e2c558         __pthread_kill
1   libsystem_pthread.dylib         0x206ab2114         pthread_kill
2   libsystem_c.dylib               0x1ae636174         abort
3   libsystem_malloc.dylib          0x1b55740e0         malloc_vreport
4   libsystem_malloc.dylib          0x1b5574388         malloc_zone_error
5   libsystem_malloc.dylib          0x1b5573cec         _tiny_check_and_zero_inline_meta_from_freelist
6   libsystem_malloc.dylib          0x1b55592a8         tiny_malloc_from_free_list
7   libsystem_malloc.dylib          0x1b5559894         tiny_malloc_should_clear
8   libsystem_malloc.dylib          0x1b555ca58         szone_malloc_should_clear
9   libsystem_malloc.dylib          0x1b556c6f8         nanov2_allocate_outlined
10  Foundation                      0x1a141367c         -[NSConcreteMutableData initWithLength:]
11  Foundation                      0x1a14134e4         -[NSString(NSStringOtherEncodings) dataUsingEncoding:allowLossyConversion:]
12  Sentry.framework                0x101d37738         encodeObject (Sentry.framework:326)
13  Sentry.framework                0x101d37c54         encodeObject (Sentry.framework:384)
14  Sentry.framework                0x101d37608         +[SentryCrashJSONCodec encode:options:error:] (Sentry.framework:427)
15  Sentry.framework                0x101d497dc         -[SentryCrashScopeObserver toJSONEncodedCString:] (Sentry.framework:149)
16  Sentry.framework                0x101d49718         -[SentryCrashScopeObserver syncScope:serialize:syncToSentryCrash:] (Sentry.framework:136)
17  Sentry.framework                0x101d49670         -[SentryCrashScopeObserver syncScope:syncToSentryCrash:] (Sentry.framework:110)
18  Sentry.framework                0x101d8686c         -[SentryScope setExtraValue:forKey:] (Sentry.framework:258)
19  Sentry.framework                0x101d63340         -[SentryHub configureScope:] (Sentry.framework:555)
20  Sentry.framework                0x101d8af90         +[SentrySDK configureScope:] (Sentry.framework:406)

The culprit is here

sentry-cocoa/Sources/SentryCrash/Recording/Tools/SentryCrashJSONCodecObjC.m

Lines 318 to 332 in eae2b59

	static int
	encodeObject(
	SentryCrashJSONCodec *codec, id object, NSString *name, SentryCrashJSONEncodeContext *context)
	{
	int result;
	const char *cName = [name UTF8String];
	if ([object isKindOfClass:[NSString class]]) {
	NSData *data = [object dataUsingEncoding:NSUTF8StringEncoding];
	result = sentrycrashjson_addStringElement(context, cName, data.bytes, (int)data.length);
	if (result == SentryCrashJSON_ERROR_INVALID_CHARACTER) {
	codec.error = sentryErrorWithDomain(
	@"SentryCrashJSONCodecObjC", 0, @"Invalid character in %@", object);
	}
	return result;
	}

Looking at the stacktrace, it seems like we can't allocate enough memory to encode the NSString to NSData. As this code is called from the scope observer, this could happen if some of our users try to put a very large string to the scope. We could fix this by truncating long strings in the scope.

I also noticed that we could use dataUsingEncoding with setting allowLossyConversion:YES so the conversation looses some data such as ‘Á’ becomes ‘A’ instead of throwing the whole string away, but that isn't related to the crash.

[philipphofmann]

We now also this in 8.38.0-beta.1 in our internal SDK crashes.

[brustolin]

I was looking at the errors, and they change between two places:

here

sentry-cocoa/Sources/SentryCrash/Recording/Tools/SentryCrashJSONCodecObjC.m

Line 325 in eae2b59

NSData *data = [object dataUsingEncoding:NSUTF8StringEncoding];

and here

sentry-cocoa/Sources/SentryCrash/Recording/Tools/SentryCrashJSONCodecObjC.m

Line 366 in eae2b59

NSArray *keys = [dict allKeys];

Two places that need to allocate more memory. I don’t think the size of the information is the issue; I believe the device is already running out of memory.

I’ve attempted to send large content, such as a 10MB text as scope tag value, which we don’t even support sending. However, there’s no way to break the encoding as long as there’s available memory.

I tried to stress test scope serialization with all kinds of crazy things and nothing.

I don’t think we should preemptively truncate strings to an arbitrary length when we don’t have any buffer restrictions.