断言在生产版本中被击中导致崩溃 [英] Asserts are hit in production build causing crashes

查看:137
本文介绍了断言在生产版本中被击中导致崩溃的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的项目中有几个assert(condition, "message")语句.

I have several assert(condition, "message") statements in my project.

它们用于检查开发期间不变的条件.我认为在生产/发布版本中将忽略它们(如此答案所述). 不是.相反,它们会在TestFlight测试期间导致崩溃.当我声明断言该应用程序不会崩溃时.通常有些错误,但不会崩溃.

They are used to check invariant conditions during development. I thought they would be ignored in production/release build (as stated in this answer). They are not. Instead they cause crashes during TestFlight testing. When I comment asserts the app does not crash. Something usually gets wrong a bit but it does not crash.

可以使用我的构建设置吗?

Can it be something with my build settings?

我所有的归档方案都使用发行版配置:

All my archive schemes use release configuration:

断言在Cocoa Touch Framework项目中,可用于自定义键盘扩展.

The asserts are in Cocoa Touch Framework project, that is used from custom keyboard extension.

所有项目中的所有目标(Cocoa Touch Framework和带有键盘扩展目标的主项目)都具有以下构建设置:

All the targets in all projects (Cocoa Touch Framework, and the main project with keyboard extension target) have these Build Settings:

Enable Foundation Assertions
    Debug    YES
    Release  NO

Disable Safety Checks  NO

怎么了?

Sulthan的答案显示了如何针对调试和释放版本全局禁用断言.那不是我所需要的.我希望它能按预期工作-断言应在调试中启用,而在发行版本中禁用.

Sulthan's answer shows how to disable asserts globally for both debug and relase builds. That is not what I need. I want it to work as expected - asserts should be enabled in debug but disabled in release builds.

默认情况下,它是这样工作的-在我的主项目中,它也是这样工作的.但这不适用于与该主项目链接的位于Framework项目中的断言(详细信息在此问题中).为什么?如何解决?

By default it works that way - and it also works that way in my main project. But it does not work for asserts located in Framework project that is linked from that main project (details in this question). Why? How to fix it?

推荐答案

您尝试过的选项:

Enable Foundation Assertions在预处理部分(宏)中. Swift没有经过预处理,并且不使用宏.此选项禁用NSAssertNSParameterAssert和在Objective-C中常用的类似宏.

Enable Foundation Assertions is in the preprocessing section (Macros). Swift is not preprocessed and does not use macros. This option disables NSAssert, NSParameterAssert and similar macros commonly used in Objective-C.

Disable Safety Checks是一种性能选择:

默认情况下,标准库保证内存安全.许多函数和方法记录了调用者必须满足的要求,例如有效的数组索引;即使违反要求,也可以确保内存安全.但是,违反要求可能会触发运行时错误.名称中包含"unsafe"一词的API使您可以在需要其他性能的地方显式禁用安全检查.您有责任验证使用不安全API的代码的内存安全性.如果多线程代码中存在竞争条件,也不能保证内存安全.

By default, the standard library guarantees memory safety. Many functions and methods document the requirements that must be satisfied by the caller, such as an array index being valid; memory safety is guaranteed even if a requirement is violated. However, violating a requirement can trigger a runtime error. APIs that include the word "unsafe" in their name let you explicitly disable safety checks in places where you need the additional performance. It’s your responsibility to verify the memory safety of code that uses unsafe APIs. Memory safety is also not guaranteed if there is a race condition in multithreaded code.

( Swift库参考)

您可能应该尝试在此处 (使用Other Swift Flags中的-assert-config Release).

You should probably try my answer here (use -assert-config Release in Other Swift Flags).

或者只是将断言保留在生产版本中.每个失败的断言都是一个错误,通常最好尽快了解一个错误.

Or just keep the asserts in production builds. Every failing assert is a bug and in general it's better to know about a bug as soon as possible.

这篇关于断言在生产版本中被击中导致崩溃的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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