Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datadog SDK Crash, Device Out of Memory #58

Closed
lmramirez opened this issue Mar 27, 2020 · 4 comments
Closed

Datadog SDK Crash, Device Out of Memory #58

lmramirez opened this issue Mar 27, 2020 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@lmramirez
Copy link

Describe what happened
Include any error message or stack trace if available.

The FileWriter class implemented in this SDK crashes if the device is out of memory. I have attached the stacktrace and some details below.

Additional context
Device Info

# Platform: ios
# OS Version: 12.3.1 (16F203)
# Device: iPhone 6s Plus
# RAM Free: 1.4%
# Disk Free: < 1%

Stacktrace

Fatal Exception: NSFileHandleOperationException
0  CoreFoundation                 0x18773527c __exceptionPreprocess
1  libobjc.A.dylib                0x18690f9f8 objc_exception_throw
2  CoreFoundation                 0x18763f4b0 -[NSCache init]
3  Foundation                     0x18815fb24 _NSFileHandleRaiseOperationException
4  Foundation                     0x1880f0784 -[NSConcreteFileHandle writeData:]
5  Datadog                        0x102ed0e5c specialized FileWriter.synchronizedWrite<A>(value:) (FileWriter.swift)
6  Datadog                        0x102ed1720 partial apply for specialized  + 38 (FileWriter.swift:38)
7  Datadog                        0x102ec38d4 thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
8  libdispatch.dylib              0x187174a38 _dispatch_call_block_and_release
9  libdispatch.dylib              0x1871757d4 _dispatch_client_callout
10 libdispatch.dylib              0x18711e320 _dispatch_lane_serial_drain$VARIANT$mp
11 libdispatch.dylib              0x18711ee3c _dispatch_lane_invoke$VARIANT$mp
12 libdispatch.dylib              0x1871274a8 _dispatch_workloop_worker_thread
13 libsystem_pthread.dylib        0x187355114 _pthread_wqthread
14 libsystem_pthread.dylib        0x187357cd4 start_wqthread
@lmramirez lmramirez added the bug Something isn't working label Mar 27, 2020
@ncreated
Copy link
Member

Hey @lmramirez 👋. Thanks for details, this pretty much narrows the issue to one particular place in the SDK. We will work on this with the highest priority and see what's possible to solve this issue.

As a side note - this unfortunately comes from Apple's FileHandle API limitation. Here's verbose a comment we left in our code:

func appendData(_ data: Data) {
/*
Apple documentation https://developer.apple.com/documentation/foundation/filehandle/1410936-write says
that `fileHandle.write()` raises an exception if no free space is left on the file system,
or if any other writing error occurs. Those are unchecked exceptions impossible to handle in Swift.
It was already escalated to Apple in Swift open source project discussion:
https://forums.swift.org/t/pitch-replacement-for-filehandle/5177
Until better replacement is provided by Apple, the SDK sticks to this API. To mitigate the risk of
crashing client applications, other precautions are implemented carefuly.
*/
fileHandle.write(data)
}

We'll try to install additional checks around to mitigate this as much as possible.

@lmramirez
Copy link
Author

@ncreated thank you!

I'm familiar with the same issue since we actually ran into it in our application. For what it's worth, we ended up implementing an objective-c method to catch the exceptions. Not super pretty, but seems wo work well. Posting here in case it's helpful:

#import "ObjCExceptions.h"

@implementation ObjCExceptions

+ (BOOL)catchException:(void(^)(void))tryBlock error:(__autoreleasing NSError **)error {
    @try {
        tryBlock();
        return YES;
    }
    @catch (NSException *exception) {
        *error = [[NSError alloc] initWithDomain:exception.name code:0 userInfo:exception.userInfo];
        return NO;
    }
}

@end

There is probably a nicer way to do this using a function instead of a static method too.

@ncreated
Copy link
Member

Thank you @lmramirez 💪. This might be tricky as SPM doesn't allow mixing Obj-C with Swift code inside single package, and separating packages will not work easily for Cocoa Pods, but we'll have a look and fix this ASAP.

@ncreated
Copy link
Member

ncreated commented Apr 7, 2020

Fixed in 1.0.1

@ncreated ncreated closed this as completed Apr 7, 2020
@ncreated ncreated self-assigned this Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants