search

parse-community / Parse-SDK-iOS-OSX

The Apple SDK for Parse Platform (iOS, macOS, watchOS, tvOS)
https://parseplatform.org
Other
2.81k stars 871 forks source link

PFFile raises exception when getting data from caches #528

Closed frangulyan closed 8 years ago

frangulyan commented 9 years ago

I'm getting this crash from time to time on app startup when trying to fetch user's profile image:

2015-11-08 13:23:15.088 MyApp[7219:471946] [Error]: Caught "NSInvalidArgumentException" with reason "*\ -[_NSPlaceholderData initWithContentsOfFile:options:error:]: nil file argument": ( 0 CoreFoundation 0x0000000110a07f45 exceptionPreprocess + 165 1 libobjc.A.dylib 0x000000011047edeb objc_exception_throw + 48 2 CoreFoundation 0x0000000110a07e7d +[NSException raise:format:] + 205 3 Foundation 0x000000011002cd48 -[NSData(NSData) initWithContentsOfFile:options:error:] + 95 4 Foundation 0x00000001100c5fcc +[NSData(NSData) dataWithContentsOfFile:options:error:] + 61 5 MyApp 0x000000010e828426 -[PFFile _cachedData] + 94 6 MyApp 0x000000010e886cac 62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke + 83 7 MyApp 0x000000010e88658c 55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 82 8 MyApp 0x000000010e8874ab 29+[BFExecutor defaultExecutor]_block_invoke_2 + 358 9 MyApp 0x000000010e887a15 -[BFExecutor execute:] + 65 10 MyApp 0x000000010e886510 55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke + 138 11 MyApp 0x000000010e886110 -[BFTask runContinuations] + 396 12 MyApp 0x000000010e8859c6 -[BFTask trySetResult:] + 151 13 MyApp 0x000000010e883c4c -[BFTaskCompletionSource trySetResult:] + 79 14 MyApp 0x000000010e7e48b3 28-[PFAsyncTaskQueue enqueue:]_block_invoke_2 + 198 15 MyApp 0x000000010e88658c __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 82 16 libdispatch.dylib 0x00000001145fce5d _dispatch_call_block_and_release + 12 17 libdispatch.dylib 0x000000011461d49b _dispatch_client_callout + 8 18 libdispatch.dylib 0x0000000114605bef _dispatch_root_queue_drain + 1829 19 libdispatch.dylib 0x00000001146054c5 _dispatch_worker_thread3 + 111 20 libsystem_pthread.dylib 0x000000011494ea9d _pthread_wqthread + 729 21 libsystem_pthread.dylib 0x000000011494c3dd start_wqthread + 13 ).

This seems to start happening after I recently updated the Parse SDK. Does this mean that file's cache is not somehow compatible with old cache or this is just a bug? Reinstalling the app has fixed it for now.

nlutsenko commented 8 years ago

Super strange and shouldn't happen. I'll try to look into it, but overall - it should be definitely there or simply redownloaded. Any chance you can post the stack trace for all threads of the app the moment it crashes? Or better - whilst debugger is attached - post a file path of the file its trying to get the file from. Also, are you trying to get the file path for the file that was saved to Parse? (Meaning that the url of e the file should be non-nil).

parse-github-bot commented 8 years ago

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:

dtaitz commented 8 years ago

@nlutsenko Any update on this. I similarly cannot receive errors when I try to load PFFiles.

nlutsenko commented 8 years ago

@dtaitz Any chance you can post the stack trace for all threads of the app the moment it crashes?

Or better - whilst debugger is attached - post a file path of the file its trying to get the file from. Also, are you trying to get the file path for the file that was saved to Parse? (Meaning that the url of the file should be non-nil).

dtaitz commented 8 years ago

@nlutsenko The app doesn't crash. I just get a lot of errors and the the images do not load from the file. The images are definitely saved to Parse.

There is definitely a change I am trying to load nil PFFile's, but that had not been a problem in the past. I am using the PFImageView ParseUI element.

Here is the backtrace: (lldb) bt all thread #1: tid = 0x35c026, 0x000000019acd0b3c libsystem_kernel.dylibsyscall_thread_switch + 8, queue = 'com.apple.main-thread' frame #0: 0x000000019acd0b3c libsystem_kernel.dylibsyscall_thread_switch + 8 frame #1: 0x000000019adad534 libsystem_platform.dylib_os_lock_handoff_lock_slow + 120 frame #2: 0x000000019ad15524 libsystem_malloc.dylibszone_malloc_should_clear + 116 frame #3: 0x000000019ad15468 libsystem_malloc.dylibmalloc_zone_malloc + 116 frame #4: 0x00000001856aa718 CoreFoundation_CFRuntimeCreateInstance + 316 frame #5: 0x00000001862b9328 CoreTextCTFontDescriptorCreateCopyWithFeature + 48 frame #6: 0x000000018b6fc1c0 UIKit-[UIStatusBarForegroundStyleAttributes proportionalFontForFont:] + 212 frame #7: 0x000000018b6fc0c4 UIKit-[UIStatusBarForegroundStyleAttributes makeTextFontForStyle:] + 184 frame #8: 0x000000018adae544 UIKit-[UIStatusBarForegroundStyleAttributes textFontForStyle:] + 124 frame #9: 0x000000018b6fbb84 UIKit-[UIStatusBarForegroundStyleAttributes imageWithText:ofItemType:forWidth:lineBreakMode:letterSpacing:textAlignment:style:withLegibilityStyle:legibilityStrength:] + 312 frame #10: 0x000000018adae3c4 UIKit-[UIStatusBarItemView imageWithText:] + 264 frame #11: 0x000000018adae168 UIKit-[UIStatusBarItemView updateContentsAndWidth] + 40 frame #12: 0x000000018ad54684 UIKit-[UIStatusBarItemView setStatusBarData:actions:] + 104 frame #13: 0x000000018ad545b8 UIKit-[UIStatusBarLayoutManager _updateItemView:withData:actions:animated:] + 156 frame #14: 0x000000018ad5441c UIKit-[UIStatusBarLayoutManager updateItemsWithData:actions:animated:] + 232 frame #15: 0x000000018ad53db4 UIKit-[UIStatusBarForegroundView _setStatusBarData:actions:animated:] + 1024 frame #16: 0x000000018ad53778 UIKit-[UIStatusBarForegroundView setStatusBarData:actions:animated:] + 688 frame #17: 0x000000018ad52854 UIKit-[UIStatusBar statusBarServer:didReceiveStatusBarData:withActions:] + 188 frame #18: 0x000000018ad52750 UIKit_UIStatusBarReceivedStatusBarDataAndActions + 76 frame #19: 0x000000018ad526bc UIKit_XReceivedStatusBarDataAndActions + 96 frame #20: 0x000000018c8e3398 AppSupportmigHelperRecievePortCallout + 212 frame #21: 0x0000000185784c7c CoreFoundation__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 56 frame #22: 0x00000001857843b4 CoreFoundationCFRunLoopDoSource1 + 436 frame #23: 0x000000018578210c CoreFoundation`CFRunLoopRun + 1800 frame #24: 0x00000001856b0ca0 CoreFoundationCFRunLoopRunSpecific + 384 frame #25: 0x00000001908ec088 GraphicsServicesGSEventRunModal + 180 frame #26: 0x000000018adc8ffc UIKitUIApplicationMain + 204 frame #27: 0x00000001001c2b8c Planvanmain(argc=1, argv=0x000000016fdc7b00) + 124 at main.m:17 frame #28: 0x000000019abce8b8 libdyld.dylib`start + 4

thread #3: tid = 0x35c05b, 0x000000019acec4fc libsystem_kernel.dylibkevent_qos + 8, queue = 'com.apple.libdispatch-manager' frame #0: 0x000000019acec4fc libsystem_kernel.dylibkevent_qos + 8 frame #1: 0x0000000100cd6328 libdispatch.dylib_dispatch_mgr_invoke + 232 frame #2: 0x0000000100cc3ee4 libdispatch.dylib_dispatch_mgr_thread + 52

thread #5: tid = 0x35c05e, 0x000000019aceb440 libsystem_kernel.dylib__semwait_signal + 8 frame #0: 0x000000019aceb440 libsystem_kernel.dylibsemwait_signal + 8 frame #1: 0x000000019ac09e2c libsystem_c.dylibnanosleep + 212 frame #2: 0x00000001999e6314 libc++.1.dylibstd::1::this_thread::sleep_for(std::1::chrono::duration<long long, std::1::ratio<1l, 1000000000l> > const&) + 84 frame #3: 0x000000018737dcf4 JavaScriptCorebmalloc::Heap::scavenge(std::__1::unique_lock<bmalloc::StaticMutex>&, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000l> >) + 404 frame #4: 0x000000018737d8cc JavaScriptCorebmalloc::Heap::concurrentScavenge() + 84 frame #5: 0x000000018737fe0c JavaScriptCorebmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::entryPoint() + 100 frame #6: 0x000000018737fd9c JavaScriptCorebmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::)()>::pthreadEntryPoint(void) + 12 frame #7: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156 frame #8: 0x000000019adb3a8c libsystem_pthread.dylib_pthread_start + 156

thread #6: tid = 0x35c05f, 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8, name = 'WebThread' frame #0: 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8 frame #1: 0x000000019acd08bc libsystem_kernel.dylibmach_msg + 72 frame #2: 0x0000000185784108 CoreFoundationCFRunLoopServiceMachPort + 196 frame #3: 0x0000000185781e0c CoreFoundation`CFRunLoopRun + 1032 frame #4: 0x00000001856b0ca0 CoreFoundationCFRunLoopRunSpecific + 384 frame #5: 0x00000001972be54c WebCoreRunWebThread(void*) + 456 frame #6: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156 frame #7: 0x000000019adb3a8c libsystem_pthread.dylib_pthread_start + 156

thread #7: tid = 0x35c061, 0x000000019aceba38 libsystem_kernel.dylib__unlink + 8, queue = 'PFSQLiteDatabase.synchronizationQueue' frame #0: 0x000000019aceba38 libsystem_kernel.dylibunlink + 8 frame #1: 0x000000019acd3cd4 libsystemkernel.dylibunlink + 16 frame #2: 0x000000019a8cc028 libsqlite3.dyliblldb_unnamed_function227$$libsqlite3.dylib + 48 frame #3: 0x000000019a8b361c libsqlite3.dylib___lldb_unnamed_function146$$libsqlite3.dylib + 1868 frame #4: 0x000000019a8b2bac libsqlite3.dylib_lldb_unnamedfunction144$$libsqlite3.dylib + 172 frame #5: 0x000000019a885b80 libsqlite3.dylib`lldb_unnamed_function54$$libsqlite3.dylib + 1860 frame #6: 0x000000019a8ad368 libsqlite3.dylib___lldb_unnamed_function114$$libsqlite3.dylib + 52044 frame #7: 0x000000019a89f87c libsqlite3.dylibsqlite3_step + 504 frame #8: 0x0000000100439350 Planvan__30-[PFSQLiteDatabaseResult step]_block_invoke_2(.block_descriptor=<unavailable>) + 88 at PFSQLiteDatabaseResult.m:42 frame #9: 0x00000001004392c8 Planvan30-[PFSQLiteDatabaseResult step]_block_invoke(.block_descriptor=0x000000016e31a560) + 120 at PFSQLiteDatabaseResult.m:42 frame #10: 0x000000010043e2cc PlanvanPFThreadsafetySafeDispatchSync(queue=0x000000013d5b1f30, block=(Planvan__30-[PFSQLiteDatabaseResult step]_block_invoke at PFSQLiteDatabaseResult.m:42)) + 152 at PFThreadsafety.m:29 frame #11: 0x00000001004391e4 Planvan-[PFSQLiteDatabaseResult step](self=0x000000013d688f10, _cmd="step") + 164 at PFSQLiteDatabaseResult.m:42 frame #12: 0x000000010043755c Planvan57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke_2(.block_descriptor=, task=0x000000013d685960) + 96 at PFSQLiteDatabase.m:240 frame #13: 0x00000001002217a4 Planvan__62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke(.block_descriptor=<unavailable>, task=0x000000013d685960) + 172 at BFTask.m:412 frame #14: 0x0000000100220a74 Planvan55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2(.block_descriptor=) + 124 at BFTask.m:338 frame #15: 0x000000010021d06c Planvan`31+[BFExecutor immediateExecutor]_block_invoke_2(.block_descriptor=0x00000001007221b0, block=(Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 at BFTask.m:330)) + 64 at BFExecutor.m:60 frame #16: 0x000000010021d894 Planvan-[BFExecutor execute:](self=0x000000013d55a670, _cmd="execute:", block=%28Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 at BFTask.m:330%29) + 108 at BFExecutor.m:111 frame #17: 0x000000010022099c Planvan55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke(.block_descriptor=0x000000013e8257c0) + 228 at BFTask.m:330 frame #18: 0x00000001002207f8 Planvan-[BFTask continueWithExecutor:block:cancellationToken:](self=0x000000013d685960, _cmd="continueWithExecutor:block:cancellationToken:", executor=0x000000013d55a670, block=%28Planvan62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke at BFTask.m:408%29, cancellationToken=0x0000000000000000) + 608 at BFTask.m:381 frame #19: 0x0000000100221698 Planvan-[BFTask continueWithExecutor:successBlock:cancellationToken:](self=0x000000013d685960, _cmd="continueWithExecutor:successBlock:cancellationToken:", executor=0x000000013d55a670, block=(Planvan57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke_2 at PFSQLiteDatabase.m:238), cancellationToken=0x0000000000000000) + 332 at BFTask.m:408 frame #20: 0x000000010022150c Planvan-[BFTask continueWithExecutor:withSuccessBlock:](self=0x000000013d685960, _cmd="continueWithExecutor:withSuccessBlock:", executor=0x000000013d55a670, block=(Planvan57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke_2 at PFSQLiteDatabase.m:238)) + 116 at BFTask.m:398 frame #21: 0x00000001004374b4 Planvan__57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke(.block_descriptor=<unavailable>) + 224 at PFSQLiteDatabase.m:236 frame #22: 0x000000010021f498 Planvan37+[BFTask taskFromExecutor:withBlock:]_block_invoke(.block_descriptor=, task=0x000000013e855b40) + 80 at BFTask.m:176 frame #23: 0x0000000100220a74 Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2(.block_descriptor=<unavailable>) + 124 at BFTask.m:338 frame #24: 0x0000000100cc1c68 libdispatch.dylib_dispatch_client_callout + 16 frame #25: 0x0000000100ccd4ec libdispatch.dylib_dispatch_barrier_sync_f_slow + 908 frame #26: 0x000000010043e2dc PlanvanPFThreadsafetySafeDispatchSync(queue=0x000000013d5b1f30, block=(Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 at BFTask.m:330)) + 168 at PFThreadsafety.m:31 frame #27: 0x0000000100435a84 Planvan33-[PFSQLiteDatabase initWithPath:]_block_invoke_2(.block_descriptor=) + 60 at PFSQLiteDatabase.m:77 frame #28: 0x0000000100cc1ca8 libdispatch.dylib_dispatch_call_block_and_release + 24 frame #29: 0x0000000100cc1c68 libdispatch.dylib_dispatch_client_callout + 16 frame #30: 0x0000000100cd0ec8 libdispatch.dylib_dispatch_root_queue_drain + 2344 frame #31: 0x0000000100cd0590 libdispatch.dylib_dispatch_worker_thread3 + 132 frame #32: 0x000000019adb1470 libsystem_pthread.dylib`_pthread_wqthread + 1092

thread #8: tid = 0x35c06f, 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8, name = 'com.apple.CoreMotion.MotionThread' frame #0: 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8 frame #1: 0x000000019acd08bc libsystem_kernel.dylibmach_msg + 72 frame #2: 0x0000000185784108 CoreFoundationCFRunLoopServiceMachPort + 196 frame #3: 0x0000000185781e0c CoreFoundation`CFRunLoopRun + 1032 frame #4: 0x00000001856b0ca0 CoreFoundationCFRunLoopRunSpecific + 384 frame #5: 0x00000001856fe44c CoreFoundationCFRunLoopRun + 112 frame #6: 0x00000001861362e4 CoreMotion___lldb_unnamed_function2150$$CoreMotion + 828 frame #7: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156 frame #8: 0x000000019adb3a8c libsystem_pthread.dylib`_pthread_start + 156

frangulyan commented 8 years ago

Sorry for late response - I cannot reproduce this anymore after I have uninstalled the app and installed it back. Most probably it was caused by parse sdk update when the app installed was once run with an older sdk. There is also another guy having the same problem here https://groups.google.com/d/msg/parse-developers/c2HL3kmqWWU/XehgdSlqCQAJ

last comment in that thread is mine so just ignore it - i copied it here.

frangulyan commented 8 years ago

FYI - in my case the app was also not crashing, just not loading the files from cache and showing in the console the exception I originally posted. Seems like the exception was caught somewhere.

dtaitz commented 8 years ago

My issue seems to be different that the one on the Parse Developers Google Group thread. I am not getting an NSException, but instead I receive the following error each and every time I try to load a PFFile image:

[Error]: Response status code was unacceptable: 400 (Code: 1, Version: 1.9.1)

frangulyan commented 8 years ago

Ok then I guess you should open a new issue. BTW, I got the error again, I will try to dump some data here...

dtaitz commented 8 years ago

@nlutsenko should I move this off to a new thread? I started one a day ago. Issue #536

frangulyan commented 8 years ago

@nlutsenko you were right, the url is null....

What I'm doing is fetching the user in background to update all the fields. Then, when finished, doing a check like this:

PFFile *userImageFile = user[@"picture"];
if ((userImageFile == nil) || [userImageFile isKindOfClass:[NSNull class]]) {
    // no image is stored in DB
    return;
}
NSLog(@"user image url %@", userImageFile.url);

In this particular case the PFFile is ok but the url is null - the above code outputs "user image url (null)". Although there IS a valid image stored on Parse side in that column. If this is normal then let me know how to get my image and feel free to close this issue.

Thanks!

nlutsenko commented 8 years ago

@frangulyan Can you point me to the URL that you see on the server? Also - your app name would help tremendously, since I can't really reproduce an issue without looking at the way the image is stored here.

nlutsenko commented 8 years ago

@frangulyan, could you tell me the user objectId where you have this file attached? The thing is - we don't ever expect for a URL to be nil for any file that is being fetched from parse.com

If you use the REST API via say, curl, - does it return a file field with null url as well?

frangulyan commented 8 years ago

Sure, the user id is IhfZepZ8SW, column "picture". I'm not familiar with REST API so I'm not sure that I will be able to make that request without some help :)

nlutsenko commented 8 years ago

@frangulyan The URL that you posted above is different from the one that is stored on Parse (that's still OK). I tried via REST API myself - it works great, nvm.

Can you attach a repro project here, or send it to nlutsenko (at) fb.com, I can't seem to reproduce an issue at all.

frangulyan commented 8 years ago

The thing is that after reinstalling the app the issue is usually gone. I just dumped the file attributes and got name='file' (which is not the file name on Parse) url='null' and 'isDirty'=1. One short clarification on the logic to understand if I'm doing it right. I'm doing fetchInBackgroundWithBlock on user and when it's done I'm taking its file column. Should I also fetch this file column to fill the info in that PFFile or fetching the user will bring everything needed to immediately call getDataInBackgroundWithBlock?

nlutsenko commented 8 years ago

Fetching the user should download all the fields for that user automatically, including all the required information for the file field. As I said before, since I can't reproduce the issue locally - can you attach or send a repro project? That would be a tremendous help in identifying why this issue happens for you as well as will speed up fixing it.

frangulyan commented 8 years ago

I just reinstalled the app (it's in simulator but I noticed similar stuff on the device) and the issue is gone. The file properties are name='tfss-b73775f4-660d-490a-942f-3491998082a5-profile.png' url='https://files.parsetfss.com/7c0e4c0f-b1b8-41c4-a38e-fc23addfe59f/tfss-b73775f4-660d-490a-942f-3491998082a5-profile.png' isDirty='0'.

I guess sending a repro project will not help you since you will not be able to reproduce just like I cannot after the reinstall. But maybe creating a small project and being able to reproduce will work, if I would also send you some files and caches from apps directories.

Anyway, I will get to it tomorrow, it's 3:30 AM in Germany and I need to wake up soon for work...

Дуже дякую ;)

nlutsenko commented 8 years ago

Sounds good :wink: Any kind of repro would work great!

frangulyan commented 8 years ago

Hey Nikita,

I'm terribly sorry, after digging and debugging for 3 hours it comes out to be my bug.

What happens is that I fetch PFUser data which brings PFFile in one of the columns (user picture). Then I download it, use it in UI and everything is fine. But at some point I (wrongly) assign a new PFFile with same image data to that column (kind of user wants to upload a new picture):

NSData *imageData = UIImagePNGRepresentation(userImage);
PFFile *imageFile = [PFFile fileWithName:@"profile.png" data:imageData];
user[@"picture"] = imageFile;

After those lines the url becomes null - which I assume to be OK since the file is not yet uploaded to Parse. Then I guess sometimes I was doing some actions which were saving the whole user data (like changing email). Restarting the app was either crashing during a fetch try (if I didn't save before and the file was loaded from local data store with null url) or working normally (if I saved it before).

Does this all make sense to you or it is still not the behaviour that you would expect and I missed something? Seems to me it's kind of dangerous to have newly created and not uploaded PFFiles between app runs, or I'm not following the best practices.

P.S. when you said above that you see the image but under different path it should have been a signal for me that I'm saving the same image every time. I must have a lot of dangling files there, need to check and cleanup.

nlutsenko commented 8 years ago

Hey @frangulyan, that sounds about right. I am glad you were able to find the reason behind this.

Not sure how you end up with an unsaved image on currentUser, since it shouldn't allow you to persist it locally. One thing that comes to my mind - is that your user gets persisted somehow on a failed save to disk, but the file is not yet uploaded, so it persists the file with a nil URL.

I would suggest adding a check for url on your user object there, and if it doesn't have a URL - you can revert the changes for the file key by using PFUser.currentUser().revertObjectForKey("picture"), or simply try recreating the picture (if you have data for it somewhere else), or even remove the dangling file for that key.

I still am curious on how you end up with an unsaved file on a currentUser() object, since we don't epxect this behavior for any given PFFile and it shouldn't happen.

frangulyan commented 8 years ago

Ok I found a way to reproduce it and isolated in a small piece of code for you. I will send the test project to the email you mentioned above.

frangulyan commented 8 years ago

I've sent it. Since it is the whole project including the frameworks it is a bit heavy - 17MB. Hopefully it will reach you without problems, let me know if you got it and are able to reproduce the issue.

nlutsenko commented 8 years ago

@frangulyan got the project, am able to reproduce an issue, turns out to be an absolutely valid way of doing this and it's indeed a bug in our code.

Looking into ways to fix it... Likely will simply attach a pull request to this issue and auto-close by merging that fix.

nlutsenko commented 8 years ago

Multiple actionables:

Current workaround for your case: Persist the file you are going to save to a different place in addition to PFFile if you care about cross-app run persistence, since this is not yet supported on PFFiles. You will also be able to look at the error on trying to get/save the unsaved PFFile without a URL and local file, and reset that field to a new file that you've persisted elsewhere.

frangulyan commented 8 years ago

I will do that, I'm glad I could help! Also your support was amazing, thanks :)