Skip to content

-[__NSCFDictionary UTF8String]: unrecognized selector sent to instance #414

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

Closed
xissburg opened this issue Oct 14, 2015 · 8 comments
Closed

Comments

@xissburg
Copy link

I am converting my project to Swift 2 in order to use the latest version of Parse SDK and hopefully get rid of deadlocks #398. Now I am facing this crash:

2015-10-14 20:15:46.388[7438:2578283] -[__NSCFDictionary UTF8String]: unrecognized selector sent to instance 0x170a74340
-[__NSCFDictionary UTF8String]: unrecognized selector sent to instance 0x170a74340

(lldb) bt
* thread #4: tid = 0x27576b, 0x00000001955bc0a8 libobjc.A.dylib`objc_exception_throw, queue = 'com.parse.dateFormatter', stop reason = breakpoint 1.1
  * frame #0: 0x00000001955bc0a8 libobjc.A.dylib`objc_exception_throw
    frame #1: 0x00000001839472f4 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 220
    frame #2: 0x00000001839440a8 CoreFoundation`___forwarding___ + 928
    frame #3: 0x000000018384696c CoreFoundation`_CF_forwarding_prep_0 + 92
    frame #4: 0x00000001006bf94c Common`__34-[PFDateFormatter dateFromString:]_block_invoke + 40
    frame #5: 0x00000001019d4f94 libdispatch.dylib`_dispatch_client_callout + 16
    frame #6: 0x00000001019df08c libdispatch.dylib`_dispatch_barrier_sync_f_invoke + 128
    frame #7: 0x00000001006bf870 Common`-[PFDateFormatter dateFromString:] + 172
    frame #8: 0x000000010067d534 Common`-[PFObject(Private) mergeFromRESTDictionary:withDecoder:] + 236
    frame #9: 0x00000001006e1810 Common`__51-[PFOfflineStore fetchObjectLocallyAsync:database:]_block_invoke168 + 72
    frame #10: 0x0000000100652648 Common`__62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke + 92
    frame #11: 0x0000000100651eec Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 88
    frame #12: 0x0000000100652e7c Common`__29+[BFExecutor defaultExecutor]_block_invoke_2 + 336
    frame #13: 0x0000000100653390 Common`-[BFExecutor execute:] + 76
    frame #14: 0x0000000100651e64 Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke + 136
    frame #15: 0x0000000100651cd4 Common`-[BFTask continueWithExecutor:block:cancellationToken:] + 324
    frame #16: 0x00000001006525a8 Common`-[BFTask continueWithExecutor:successBlock:cancellationToken:] + 204
    frame #17: 0x00000001006526e8 Common`-[BFTask continueWithSuccessBlock:] + 100
    frame #18: 0x00000001006e1544 Common`__51-[PFOfflineStore fetchObjectLocallyAsync:database:]_block_invoke134 + 444
    frame #19: 0x0000000100652648 Common`__62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke + 92
    frame #20: 0x0000000100651eec Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 88
    frame #21: 0x0000000100652e7c Common`__29+[BFExecutor defaultExecutor]_block_invoke_2 + 336
    frame #22: 0x0000000100653390 Common`-[BFExecutor execute:] + 76
    frame #23: 0x0000000100651e64 Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke + 136
    frame #24: 0x0000000100651a70 Common`-[BFTask runContinuations] + 356
    frame #25: 0x00000001006512e0 Common`-[BFTask trySetResult:] + 152
    frame #26: 0x0000000100651214 Common`-[BFTask setResult:] + 20
    frame #27: 0x000000010064f510 Common`-[BFTaskCompletionSource setResult:] + 80
    frame #28: 0x0000000100651fbc Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 296
    frame #29: 0x0000000100652e7c Common`__29+[BFExecutor defaultExecutor]_block_invoke_2 + 336
    frame #30: 0x0000000100653390 Common`-[BFExecutor execute:] + 76
    frame #31: 0x0000000100651e64 Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke + 136
    frame #32: 0x0000000100651a70 Common`-[BFTask runContinuations] + 356
    frame #33: 0x00000001006512e0 Common`-[BFTask trySetResult:] + 152
    frame #34: 0x0000000100651214 Common`-[BFTask setResult:] + 20
    frame #35: 0x000000010064f510 Common`-[BFTaskCompletionSource setResult:] + 80
    frame #36: 0x00000001006521ac Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 + 300
    frame #37: 0x0000000100651fa0 Common`__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 268
    frame #38: 0x00000001019d4fd4 libdispatch.dylib`_dispatch_call_block_and_release + 24
    frame #39: 0x00000001019d4f94 libdispatch.dylib`_dispatch_client_callout + 16
    frame #40: 0x00000001019dfdb8 libdispatch.dylib`_dispatch_queue_drain + 780
    frame #41: 0x00000001019d82c4 libdispatch.dylib`_dispatch_queue_invoke + 132
    frame #42: 0x00000001019e25d4 libdispatch.dylib`_dispatch_root_queue_drain + 772
    frame #43: 0x00000001019e4248 libdispatch.dylib`_dispatch_worker_thread3 + 132
    frame #44: 0x0000000195e1921c libsystem_pthread.dylib`_pthread_wqthread + 816

I am using the local datastore by the way and after using the app for a while it will save some stuff to the local datastore and eventually it will crash when retrieving this data. Then it will crash on start up on the next runs, with this exact same error.

@nlutsenko
Copy link
Contributor

Hey @xissburg, thanks for the report.
This sounds super strange, since it's first report of this kind.
Few questions that would help address/investigate this issue faster:

  • how do you get the data for these objects from the server?
  • at the moment of crash - could you print out the value that it calls UTF8String on?

@parse-github-bot
Copy link

Thank you for your feedback. We prioritize issues that have clear and concise repro steps. Please see our Bug Reporting Guidelines about what information should be added to this issue.

Please try the latest SDK. Our release notes have details about what issues were fixed in each release.

In addition, you might find the following resources helpful:

@xissburg
Copy link
Author

@nlutsenko This is what I get as the parameter of -[PFDateFormatter dateFromString:] at the time of crash, a dictionary:

{
    "__type" = Date;
    iso = "2015-10-14T23:25:24.049Z";
}

I get the objects via a query and pin them afterwards.

@nlutsenko
Copy link
Contributor

Last question around this - in the frame #8 of the stack trace aka -[PFObject(Private) mergeFromRESTDictionary:withDecoder:] can you grab a field of the object that we are trying to decode this for?

What looks like is happening is that server is returning a Date json type, instead of a string for updatedAt/createdAt, which leads us to not handle this...
I am trying to figure out whether this is a bigger problem, like backend sending wrong data to the client or purely a client piece.

Anyhow - we should safeguard these, I am going to send a PR in a bit.

@xissburg
Copy link
Author

This is one object that is passed to -[PFObject mergeFromRESTDictionary:withDecoder:] before the crash:

{
    ACL =     {
        1Nii4IsZc1 =         {
            read = 1;
            write = 1;
        };
        WlGMIfGqOi =         {
            read = 1;
            write = 1;
        };
    };
    "__complete" = 1;
    "__operations" =     (
                {
            "__updatedAt" =             {
                "__type" = Date;
                iso = "2015-10-14T23:25:25.377Z";
            };
            "__uuid" = "85CBB991-8E84-4BBE-BE27-E3FDB7ED420E";
        }
    );
    author =     {
        "__type" = Pointer;
        className = "_User";
        objectId = 1Nii4IsZc1;
    };
    body = "The only one of those days";
    chat =     {
        "__type" = Pointer;
        className = Chat;
        objectId = o5IWJ2bNq1;
    };
    className = ChatMessage;
    createdAt =     {
        "__type" = Date;
        iso = "2015-10-14T23:25:24.049Z";
    };
    isDeletingEventually = 0;
    objectId = vxjystz1f2;
    previousUsersRead =     (
    );
    status = 2;
    updatedAt =     {
        "__type" = Date;
        iso = "2015-10-14T23:25:24.049Z";
    };
}

@nlutsenko
Copy link
Contributor

@xissburg, according to #422 - I think what happens here is that you are setting the dates on your object manually, which is unsupported, since public properties of PFObject have readonly access set to them, according to the API ref:

/*!
 @abstract When the object was last updated.
 */
@property (PF_NULLABLE_PROPERTY nonatomic, strong, readonly) NSDate *updatedAt;

/*!
 @abstract When the object was created.
 */
@property (PF_NULLABLE_PROPERTY nonatomic, strong, readonly) NSDate *createdAt;

I am going to send a diff to restrict it further (no ability to change them via setObject:forKey:), so you can't shoot yourself in a foot.

Let me know if this is the case.

@xissburg
Copy link
Author

Wow, yes, this makes sense. Thanks very much for noticing this. I will stop being lazy and will create a dateCreated column in this class and stop messing with createdAt and updatedAt.

@nlutsenko
Copy link
Contributor

👍 Glad it helped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants