Simperium couldn't load member data (unsupported type) - simperium

Trying to add Simperium to my existing app, I get a NSAssertion error:
(gdb) po $eax
Simperium couldn't load member data (unsupported type)
Stack trace:
(gdb) bt
#0 0x02f63cbc in objc_exception_throw ()
#1 0x0190da48 in +[NSException raise:format:arguments:] ()
#2 0x00a5b2cb in -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] ()
#3 0x003ac625 in -[SPCoreDataExporter addMembersFrom:to:] (self=<value temporarily unavailable, due to optimizations>, entityDesc=<value temporarily unavailable, due to optimizations>) at /Users/kineticpoet/dev/simperium-ios-private/Simperium/SPCoreDataExporter.m:95
#4 0x003acd3b in -[SPCoreDataExporter exportModel:classMappings:] (_cmd=0x3fa641, model=0x7b377560) at /Users/kineticpoet/dev/simperium-ios-private/Simperium/SPCoreDataExporter.m:156
#5 0x00374a4d in -[Simperium startWithAppID:APIKey:model:context:coordinator:] (self=<value temporarily unavailable, due to optimizations>, _cmd=<value temporarily unavailable, due to optimizations>, model=<value temporarily unavailable, due to optimizations>) at /Users/kineticpoet/dev/simperium-ios-private/Simperium/Simperium.m:385
#6 …
What are the supported types? Are binary data supported? My app uses "Allows external storage" for binary data. Is that supported?
How can I find out more info?
UPDATE:
Extending Simperiums Simpletodo example and adding a new entity with binary data attribute leads to the same error:
…
2012-05-13 14:30:20:192 SimpletodoFinal[42429:fb03] Simperium starting...
2012-05-13 14:30:20.222 SimpletodoFinal[42429:fb03] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Simperium couldn't load member data (unsupported type)'
*** First throw call stack:
(0x17f2022 0x1bcecd6 0x179aa48 0xdda2cb 0x3fb85 0x4029b 0x7fad 0x2e37 0x441386 0x442274 0x451183 0x451c38 0x445634 0x2082ef5 0x17c6195 0x172aff2 0x17298da 0x1728d84 0x1728c9b 0x441c65 0x443626 0x290d 0x2875 0x1)
terminate called throwing an exception
Update^2:
Simperium starts sync after changing superclass of entity with binary data to non NSManagedObject class.

Simperium's support for the binary type in Core Data is currently undocumented and limited. To prevent Simperium from seeing any particular attribute (including binary attributes, which aren't yet fully supported), you can add a User Info parameter to that attribute.
Highlight the attribute in the model editor, open the inspector pane, and add a User Info parameter. Set the key to spDisableSync and the value to 1. This should allow the rest of that entity to be used successfully with Simperium (if you need it).

Related

iOS swift CTFontManagerRegisterGraphicsFont vs CTFontManagerRegisterFontsForURL

I am using CTFontManagerRegisterGraphicsFont to register CGFont loaded at runtime from various sources (files, memory, ..), but some fonts raises an Exception with the following message:
Exception: "*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0]"
an alternative to CTFontManagerRegisterGraphicsFont is CTFontManagerRegisterFontsForURL:
using this function I did not have any exception raised.
My Questions:
What is the cause of this behavior difference
How to catch & discard the exception raised by CTFontManagerRegisterGraphicsFont
Is there any thing to be done before calling CTFontManagerRegisterGraphicsFont to prevent the exception.
What .persistent scope mean for 2nd parameter in CTFontManagerRegisterFontsForURL.

Flutter: Firestore transaction crashes only on physical iOS device

I have a simple transaction that updates a Firestore document. It works correctly on Android devices, Android Emulators and iOS emulators, but crashes on a physical iOS device:
Firestore.instance.runTransaction((Transaction tx) async {
DocumentSnapshot docSnapshot = await tx.get(docRef);
tx.update(
docRef,
{
'title':'A Title'
},
);
}
Error:
-[NSError init] called; this results in an invalid NSError instance. It will raise an exception in a future release. Please call
errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This
message shown only once.
Assertion failure in void
firebase::firestore::core::Transaction::EnsureCommitNotCalled()(),
/Users/path_to_app/ios/Pods/FirebaseFirestore/Firestore/core/src/firebase/firestore/core/transaction.mm:198
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'FIRESTORE INTERNAL
ASSERTION FAILED: A transaction object cannot be used after its update
callback has been invoked. (expected !committed_)'
I'm not sure what the error means, and my Google quest has hit a dead-end. Really hoping someone can point out what the problem might be!

How to Avoid Realm-JS Crashes in React Native?

I'm working on a React Native 0.40 app that uses Realm JS 1.0.0. I am experiencing crashes when reading/writing and some odd behaviors. For example, one of the crashes only happens when I add a second record to the table.
When it crashes, the output prints:
<Error>: MY_APP(18085,0x7000075ce000) malloc: *** mach_vm_map(size=18446744073345937408) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
(this is on the iOS simulator)
I've worked with Realm in Swift projects in the past where I had to be aware not to pass objects or collections around and also to not use the same realm from multiple threads, etc. However, I don't think those issues apply to RN. Right?
My general approach is to have a Realm factory like:
realm.js
export function getUserRealm(){
const realm = new Realm({
schema: combinedSchemas,
path: `main.realm`
});
console.log( "💿 User Realm Path:", realm.path );
return realm;
}
Then I call getUserRealm() from wherever it is that I'm using realm.
There are a few places where I do pass Results between functions and callbacks.
The main question is, what should I guard against in order to prevent crashes?

Native registration to Azure hub always crashes the first time the app is launched

I've made a iOS 7.0 app that use push-notifications and the Azure Mobile services framework. All is good, but I've seen that when I clear my app (e.g., remove it from my phone to force a "first launch" use-case), the app crashes from what I assume is a bug/crash within the Azure framework?
Basically, I'm running the following code-snippet;
//Proceed and register
SBNotificationHub* hub = [[SBNotificationHub alloc] initWithConnectionString:notificationConnectionString
notificationHubPath:notificationHub];
DDLogInfo(#"Hub object = %#", hub);
//Register with native hub...
NSError* error = nil;
if (![hub registerNativeWithDeviceToken:deviceToken tags:nil error:&error])
{
//False
DDLogInfo(#"Failed to register with native hub...");
if (error)
DDLogError(#"Found error; %#", error.localizedDescription);
}
... and when registerNativeWithDeviceToken: is executed, my app crashes with the following exception;
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** setObjectForKey: key cannot be nil'
Enabling breakpoint exceptions show the following trace, indicating that it's the SBLocalStorage class, part of the Azure framework, that try to put nil in a NSDictionary;
Thread 4, Queue : NSManagedObjectContext Queue
#0 0x3bc7e1f0 in __pthread_kill ()
#9 0x30e6e1be in -[__NSDictionaryM setObject:forKey:] ()
#10 0x0022afa8 in -[SBLocalStorage updateWithRegistrationName:registration:] at /Users/admin/Desktop/Main/enlist/WindowsAzureMessaging/WindowsAzureMessaging/Helpers/SBLocalStorage.m:89
#11 0x0022ae4c in -[SBLocalStorage updateWithRegistration:] at /Users/admin/Desktop/Main/enlist/WindowsAzureMessaging/WindowsAzureMessaging/Helpers/SBLocalStorage.m:70
#12 0x00227d76 in -[SBNotificationHub retrieveAllRegistrationsWithDeviceToken:error:] at /Users/admin/Desktop/Main/enlist/WindowsAzureMessaging/WindowsAzureMessaging/SBNotificationHub.m:700
#13 0x00227202 in -[SBNotificationHub registerNativeWithDeviceToken:tags:error:] at /Users/admin/Desktop/Main/enlist/WindowsAzureMessaging/WindowsAzureMessaging/SBNotificationHub.m:458
#14 0x000b6788 in -[BackendCommunicator registerPushNotificationsForDeviceToken:] at /Users/markus/Xcode/MyApp/myApp/BackendCommunicator.m:1632
But, regardless, has anyone else seen this? And moreover, why does it work all consecutive launches, BUT NOT the first?
Best,
/Markus
I tried to reproduce the issue you described, but for me SDK works OK at this scenario. However I found and fixed serious bug.
Latest version is available on Git Hub, I've also uploaded ready-to-use binaries for your convenience: https://github.com/Azure/azure-notificationhubs/tree/master/iOS/bin.
So I would suggest you to try if it works after last fixes.

Unable to fetch related item from DynamoDB using Core Data

I have two entities with a one to one relationship between the two. In tests I can create the two entities, join and save them. The data appears in DynamoDB as expected with the appropriate ID's displayed to show the two are related.
I then attempt to retrieve the items back. I perform a fetch request for one of the items, which is returned and I can log it's identifier successfully. However, if I attempt to log the identifier of the related entity which I am expecting to have been fetched implicitly I get the following exception:
2013-01-17 15:00:13.936 DJ[10995:c07] DynamoDBResponse.m|-[DynamoDBResponse connectionDidFinishLoading:]|62|Response Body:
{"__type":"com.amazon.coral.validate#ValidationException","message":"1 validation error detected: Value null at 'key.hashKeyElement' failed to satisfy constraint: Member must not be null"}
2013-01-17 15:00:13.936 DJ[10995:c07] DynamoDBResponse.m|-[DynamoDBResponse connectionDidFinishLoading:]|92|Returned CRC32: 650439770, Calculated CRC32: 650439770
2013-01-17 15:00:13.937 DJ[10995:c07] AmazonRequestDelegate.m|-[AmazonRequestDelegate request:didFailWithServiceException:]|74|didFailWithServiceException
2013-01-17 15:00:13.937 DJ[10995:c07] DynamoDBWebServiceClient.m|-[DynamoDBWebServiceClient invoke:rawRequest:unmarshallerDelegate:]|131|Response Status Code : 400
2013-01-17 15:00:13.938 DJ[10995:c07] AmazonErrorHandler.m|+[AmazonErrorHandler errorFromExceptionWithThrowsExceptionOption:]|51|WARNING: An exception was thrown. Please call [AmazonErrorHandler shouldNotThrowExceptions] to change this behavior.
2013-01-17 15:00:13.939 DJ[10995:c07] *** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0x7540100 <x-coredata://279744BC-1B25-4170-AF2C-83676954BC3D-10995-00005B7C38D21AFA/Venue/p(null)>''
*** First throw call stack:
(0x1655012 0x147ae7e 0xe6ed8 0xe6887 0xe64c1 0xe6336 0x10b000 0x260c 0x1edc 0x4a3817 0x4a3882 0x3f2a25 0x3f2dbf 0x3f2f55 0x3fbf67 0x3bffcc 0x3c0fab 0x3d2315 0x3d324b 0x3c4cf8 0x24a2df9 0x24a2ad0 0x15cabf5 0x15ca962 0x15fbbb6 0x15faf44 0x15fae1b 0x3c07da 0x3c265c 0x282d 0x1d15)
libc++abi.dylib: terminate called throwing an exception
I have tried setting:
[request setReturnsObjectsAsFaults:NO];
but there is no difference in the result.
I am not performing any updates on the data following the initial fetch. Am I missing something?
<< EDIT 1 >>
I can see from the logging that when accessing the related object, the underlying message being sent to DynamoDB has a null key, so it is correct that DynamoDB can't fetch a result, but I don't understand why the key isnot being transmitted, as it is correctly listed in the DB.
<< EDIT 2 >>
If I add a second relationship which is one to many and add the exact same entity into it, then access the one to many relationship first, I can then retrieve the exact same object via the one to one relationship as expected . . . has anyone got an example where they have successfully used DynamoDB for a one to one relationship as this seems like a bug?
It seems DynamoDB cannot handle null or empty string values (instead, you shouldn't have an attribute at all), and that may be hitting you.
Can you do a similar query outside your app ? in the 'console' ?
I'm afraid this never got solved, but there is a more detailed thread on the AWS forums if anyone is interested - https://forums.aws.amazon.com/thread.jspa?threadID=114528&tstart=0
End result was that I could not get a one to one relationship to fire, without including the same related entity in a one to many relationship and accessing that first, even though the exact same relationship worked exactly as expected when backing onto SqlLite.

Resources