OSStatus错误代码-34018 [英] OSStatus error code -34018

查看:2168
本文介绍了OSStatus错误代码-34018的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用SecItemCopyMatching访问iOS钥匙串.从后台重新启动应用程序后,大约一百分之一的时间我得到一个-34018结果代码. 文档状态:

I am using SecItemCopyMatching to access the iOS keychain. About 1 in a hundred times I get a -34018 result code right after relaunching the app from the background. The documentation states:

为钥匙串服务分配的错误空间是不连续的: –25240至–25279和–25290至–25329.钥匙扣物品 服务还可能返回noErr(0)或paramErr(–50)或CSSM结果 代码

The assigned error space for Keychain Services is discontinuous: –25240 through –25279 and –25290 through –25329. Keychain Item Services may also return noErr (0) or paramErr (–50), or CSSM result codes

因此,看来-34018是"CSSM结果代码".我遵循了建议的链接,但是找不到结果代码.

So it seems that -34018 is a 'CSSM result code'. I have followed the suggested link but could not find result codes.

-34018结果代码是什么?如何获得更可靠的钥匙串访问?

What it the -34018 result code? How can I get more reliable keychain access?

- (NSData *)getKeychainData:(NSString *)key
{
    NSDictionary *query = @{
        (__bridge id)kSecClass:(__bridge id)kSecClassGenericPassword,
        (__bridge id)kSecAttrService:SEC_ATTR_SERVICE,
        (__bridge id)kSecAttrAccount:key,
        (__bridge id)kSecReturnData:@YES
    };

    CFDataRef result = nil;

    OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&result);

    if(status == errSecItemNotFound) {
        return nil;
    }

    if(status == noErr) {
        return CFBridgingRelease(result);
    } else {
        [self logError:[NSString stringWithFormat:@"SecItemCopyMatching status %d", (int)status] :nil];
        return nil;
    }
}

推荐答案

我一直在研究相同的错误.

I've been just researching the same error.

其要点是安全服务苹果使用它与钥匙链进行通信,在极少数情况下,当用户设备的内存不足时,崩溃并失去了应用程序与钥匙链对话的能力,这导致可怕的-34018.

The gist of it is that the security service apple uses in order to communicate with the key chain, in rare cases, when the user's device is low on memory, crashes and taking away the app ability to talk to the keychain which results the dreadful -34018.

这并非像某些人所声称的那样仅在通过Xcode运行时发生.

This is not happening only while running through Xcode like some may claim.

这是关于其中一个问题的最新数据,摘自Apple一名员工的Apple开发者论坛:

This is the most recent data regarding the issue taken from the Apple developer forums by one of the Apple staff:

更新:我们终于能够在iOS上重现-34018错误 8.3.这是确定根本原因然后提出解决方案的第一步.

UPDATE: We have finally been able to reproduce the -34018 error on iOS 8.3. This is the first step in identifying the root cause and then coming up with a fix.

和往常一样,我们无法承诺发布时间表,但这有 影响了许多开发人员,我们真的想解决这个问题.

As usual, we can't commit to a release timeframe, but this has affected many developers and we really want to get this resolved.

之前,我建议在 应用程序:didFinishLaunchingWithOptions和 applicationDidBecomeActive:以以下方式访问钥匙串之前: 解决方法.但是,这实际上并没有帮助.那意味着 除了重新启动之外,目前没有其他解决方法 该应用程序.

Earlier I suggested adding a small delay in application:didFinishLaunchingWithOptions and applicationDidBecomeActive: before accessing the keychain as a workaround. However, that doesn't actually appear to help. That means that there's no known workaround at this time other than relaunching the app.

该问题似乎与内存压力有关,所以也许 更积极地处理内存警告可以缓解此问题.

The issue appears to be related to memory pressure, so perhaps being more aggressive in handling memory warnings may alleviate the problem.

来自另一位Apple员工:

From Another Apple staff member:

  • 钥匙串工程学很清楚这个问题的重要性.
  • 主要问题一直是在苹果电脑上重现故障.
  • 我们现在能够做到这一点(很大程度上要感谢你们在归档和跟踪错误报告方面所做的工作).
  • Keychain engineering is well aware of how important this issue is.
  • The primary problem has been reproducing the failure here at Apple.
  • We're now able to do that (largely thanks to the work you guys have put in filing and following up on your bug reports).

2016年3月22日来自另一位Apple员工:

From Another Apple staff member on Mar 22, 2016:

好的,这是最新的.这是一个复杂的问题,涉及多个 可能的原因:问题的某些情况是由不正确的引起的 应用程序签名.您可以轻松区分这种情况,因为问题 是100%可复制的.问题的某些情况是由 iOS如何支持应用程序开发的错误(r.23991853).调试 操作系统中的另一个错误(r. 23,770,418)掩盖了它的作用,这意味着问题只是突然出现了 当设备处于内存压力下时.我们相信这些问题 在iOS 9.3中已解决.我们怀疑可能还有更多原因 这个问题.因此,如果您在用户设备上看到此问题(一个 运行iOS 9.3或更高版本的Xcode尚未与之对话) 请提交有关此问题的错误报告.尝试包括设备 系统登录您的错误报告(我意识到,当 处理客户设备;一种选择是要求客户 安装Apple Configurator,使他们可以查看系统日志.和 如果您确实提交了错误,请张贴您的错误号,仅用于 记录.我谨代表苹果公司感谢大家 努力帮助解决这个相当可怕的问题.分享和 享受

OK, here’s the latest. This is a complex problem with multiple possible causes: Some instances of the problem are caused by incorrect app signing. You can easily distinguish this case because the problem is 100% reproducible. Some instances of the problem are caused by a bug in how iOS supports app development (r. 23,991,853). Debugging this was complicated by the fact that another bug in the OS (r. 23,770,418) masked its effect, meaning the problem only cropped up when the device was under memory pressure. We believe these problems were resolved in iOS 9.3. We suspect that there may be yet more causes of this problem. So, if you see this problem on a user device (one that hasn’t been talked to by Xcode) that’s running iOS 9.3 or later, please do file a bug report about it. Try to include the device system log in your bug report (I realise that can be tricky when dealing with customer devices; one option is to ask the customer to install Apple Configurator, which lets them view the system log). And if you do file a bug, please post your bug number, just for the record. On behalf of Apple I’d like to thank everyone for their efforts in helping to track down this rather horrid issue. Share and Enjoy

很遗憾,没有已知的解决方法,并且在9.3.2 Beta 1(13F51a)中仍未解决该问题

这篇关于OSStatus错误代码-34018的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆