Invalid radix-16 number when writing/reading 64bit integers to a method channel on iOS 32 bit devices #21313
Labels
c: crash
Stack traces logged to the console
dependency: dart
Dart team may need to help us
e: device-specific
Only manifests on certain devices
engine
flutter/engine repository. See also e: labels.
platform-ios
iOS applications specifically
Comments
hariprasadiit
referenced
this issue
in hariprasadiit/flutter_cache_manager
Sep 1, 2018
workaround for issue where using milliseconds throws `FormatException: Invalid radix-16 number` on some `iOS` devices. check flutter/flutter#16852 (comment) for more details
|
What does it print if you change to |
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>flutter.MILLIS</key>
<string>-1813496250</string>
</dict>
</plist>
this the user default file from the device. looking at this |
|
@zoechi it throws error when i call |
Sorry, my bad. |
zoechi
added
c: crash
|
please check my first comment. because of this issue, we had to change timestamps from milliseconds to ISO Strings. this seems to be issue with |
|
comparing on else if ([method isEqualToString:@"setInt"]) {
NSString *key = arguments[@"key"];
NSNumber *value = arguments[@"value"];
// int type in Dart can come to native side in a variety of forms
// It is best to store it as is and send it back when needed.
// Platform channel will handle the conversion.
[[NSUserDefaults standardUserDefaults] setValue:value forKey:key];
result(@YES);
}on case "setInt":
Number number = call.argument("value");
Editor editor = preferences.edit();
if (number instanceof BigInteger) {
BigInteger integerValue = (BigInteger) number;
editor.putString(key, BIG_INTEGER_PREFIX + integerValue.toString(Character.MAX_RADIX));
} else {
editor.putLong(key, number.longValue());
}
status = editor.commit();is there a specific reason why big integers are not handled on |
|
Same problem here. In my case I'm accessing a boolean, but it is crashing with the same error. |
|
I met the same problem. |
|
just kidding, it resurfaced, but is only happening on iOS |
|
same problem here with device is iPhone5 32-bit. |
|
almost the same, but with cloud-firestore: |
|
This is issue is not related to |
|
it looks like shared_preferences not working at all on this kind of ios devices and it's quite a big issue :) |
|
It would seem that the flutter engine + flutter combo might not be interpreting When writing/sending a large integer in dart ( } else if (strcmp(type, @encode(unsigned long)) == 0 ||
strcmp(type, @encode(signed long long)) == 0 ||
strcmp(type, @encode(unsigned long long)) == 0) {
NSString* hex = [NSString stringWithFormat:@"%llx", number.unsignedLongLongValue];
[self writeByte:FlutterStandardFieldIntHex];
[self writeUTF8:hex];
}Instead, I believe the else if (strcmp(type, @encode(signed long)) == 0 ||
strcmp(type, @encode(unsigned int)) == 0) {
SInt64 n = number.longValue;
[self writeByte:FlutterStandardFieldInt64];
[self writeBytes:(UInt8*)&n length:8];
}On the way back from native to dart, flutter tries to read the value back as an hex (as seen in the stack trace above) and fails: case _valueLargeInt:
// Flutter Engine APIs to use large ints have been deprecated on
// 2018-01-09 and will be made unavailable.
// TODO(mravn): remove this case once the APIs are unavailable.
final int length = readSize(buffer);
final String hex = utf8.decoder.convert(buffer.getUint8List(length));
result = int.parse(hex, radix: 16); // This is line 396 shown in the logs of the 1st message of this Github issue
break;The snippet of code mentions that hex parsing has been deprecated (see https://github.com/flutter/flutter/pull/14011/files and https://github.com/flutter/engine/pull/4528/files) /cc @mravn-google Running any flutter app with the following #import <Flutter/Flutter.h>
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char* argv[]) {
@autoreleasepool {
NSLog(@"@encode(unsigned long): \t%s", @encode(unsigned long));
NSLog(@"@encode(signed long long): \t%s", @encode(signed long long));
NSLog(@"@encode(unsigned long long): \t%s", @encode(unsigned long long));
NSLog(@"-----");
NSLog(@"@encode(signed long): \t%s", @encode(signed long));
NSLog(@"@encode(unsigned int): \t%s", @encode(unsigned int));
[FlutterStandardMessageCodec sharedInstance].
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
------
iPhone 4, i0S 9.3 (32 bit)
2018-11-08 20:24:05.694 Runner[302:31558] @encode(unsigned long): L
2018-11-08 20:24:05.700 Runner[302:31558] @encode(signed long long): q
2018-11-08 20:24:05.700 Runner[302:31558] @encode(unsigned long long): Q
2018-11-08 20:24:05.701 Runner[302:31558] -----
2018-11-08 20:24:05.701 Runner[302:31558] @encode(signed long): l
2018-11-08 20:24:05.701 Runner[302:31558] @encode(unsigned int): I
iPhone 5s, i0S 12.1 (64 bit)
2018-11-08 20:25:08.654496+0000 Runner[2145:23721] @encode(unsigned long): Q
2018-11-08 20:25:08.656121+0000 Runner[2145:23721] @encode(signed long long): q
2018-11-08 20:25:08.656218+0000 Runner[2145:23721] @encode(unsigned long long): Q
2018-11-08 20:25:08.656343+0000 Runner[2145:23721] -----
2018-11-08 20:25:08.656461+0000 Runner[2145:23721] @encode(signed long): q
2018-11-08 20:25:08.656584+0000 Runner[2145:23721] @encode(unsigned int): IIn particular a I'm guessing the core of the issue is that same string value of Happy to hear your thoughts on this and if anyone can come of up with a fix, that'd be great. |
|
@hariprasadiit maybe it's worth considering changing the title of this issue to something non-plugin related? Like " That would hopefully give this issue a boost in priority as it is not related to any one plugin? |
hariprasadiit
changed the title
Invalid radix-16 number when reading milliseconds from Shared Preferences on iOS
|
Everyone who is facing this issue, please upvote so that it goes high on priority list. This is a big issue @zoechi Please remove |
zoechi
added
engine
|
News? |
jason-simmons
added a commit
to jason-simmons/flutter_engine
that referenced
this issue
Dec 5, 2018
Consistently handle Int32/Int64 types on both 32-bit and 64-bit versions of iOS. Drop usage of the obsolete hex string encoding for BigInt types. Fixes flutter/flutter#21313
jason-simmons
added a commit
to jason-simmons/flutter_engine
that referenced
this issue
Dec 6, 2018
Consistently handle Int32/Int64 types on both 32-bit and 64-bit versions of iOS. Drop usage of the obsolete hex string encoding for BigInt types. Fixes flutter/flutter#21313
|
This is a severe problem on iPhone 5. It happens after I got a crash from native part of my iOS Flutter App. On restart, impossible to get instance of shared_preferences, and the following error is shown : |
|
I hope this gets fixed soon! Is there a workaround in the time we need to wait for the real fix? |
|
@namanix i don't think so. In my case, i moved away from date in milliseconds format to ISO format. |
|
So in summary, the workaround is simply to avoid prefs.setInt() and use setString() instead, right ? |
jason-simmons
added a commit
to flutter/engine
that referenced
this issue
Dec 17, 2018
Consistently handle Int32/Int64 types on both 32-bit and 64-bit versions of iOS. Drop usage of the obsolete hex string encoding for BigInt types. Fixes flutter/flutter#21313
|
Any idea when the fix will arrived on the stable version please ? |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
shared_preferences: ^0.4.2topubspec.yamlWrite to PrefsandRead From Prefsbuttons once. You can see that, retrieving millis works fine.Read From Prefsbutton to see the error in console.NOTE
Plugin crashes when it tries to read values from User Defaults on iOS, at this line
final Map<Object, Object> fromSystem = await _kChannel.invokeMethod('getAll');Logs
flutter doctor -vThe text was updated successfully, but these errors were encountered: