开发者

app runs as debug, but crashes as release

开发者 https://www.devze.com 2023-01-08 23:23 出处:网络
I have a program which runs fine on the device in Debug configuration, but fails as a Release. Anyone have this experience, 开发者_运维百科and how do I fix it?

I have a program which runs fine on the device in Debug configuration, but fails as a Release. Anyone have this experience, 开发者_运维百科and how do I fix it?

Thx


I ran into the same problem - App worked fine on simulator and device in Debug mode, but neither in Release mode (it would install, but just display the splashscreen)

  • Xcode 4.3.2
  • iOS Deployment Target 4.3

I kept seeing answers on StackOverflow that said this was a memory management issue, but that didn't make any sense to me since the debug version worked perfectly fine when loaded to my iPhone 4S. I also checked Build Settings to see what differed between the two modes, and I skipped over the one difference that mattered in the end - compiler optimization.

In Build Settings -> under Apple LLVM compiler 3.1 code generation -> Optimization Level, change the Release setting from the default Fastest, Smallest [-Os] to None[-O0] . Fixed my issue.

Found that solution in this blog post: http://www.mindjuice.net/2011/11/30/how-to-fix-an-app-that-crashes-in-release-but-not-debug/.

The Apple Documentation helps, but doesn't explain why doing just the opposite fixes things:

Code optimizations of any kind result in slower build times because of the extra work involved in the optimization process. If your code is changing, as it does during the development cycle, you do not want optimizations enabled. As you near the end of your development cycle, though, the release build configuration can give you an indication of the size of your finished product, so the Fastest, Smallest option is appropriate.

None: The compiler does not attempt to optimize code. Use this option during development when you are focused on solving logic errors and need a fast compile time. Do not use this option for shipping your executable.

Fastest, Smallest: The compiler performs all optimizations that do not typically increase code size. This is the preferred option for shipping code because it gives your executable a smaller memory footprint.


Post

Some

Clues!

What do you mean by "fail"? Crash? Hang? Jettisoned for memory use? What are the symptoms of the failure? Got backtrace? Do you have anything in your code that behaves different in debug vs. release? Any #ifdef DEBUG type shenanigans? asserts with side effects? Did you mess with the compiler settings? Got C++? Assembly?

I see a hint of a clue in the comments; illegal access of a variable. Most likely, this is caused by the optimizer re-using a stack slot more quickly in release than debug. Which, generally, boils down to an over-release issue.

Even when building for release, you can still turn on zombie detection.

Also, have you done a build and analyze and fixed any problems it indicates?

0

精彩评论

暂无评论...
验证码 换一张
取 消