6

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

John Smith
  • 12,491
  • 18
  • 65
  • 111
  • You should see my answer to this question and it will (sorta) give you the answer to what you are looking for: http://stackoverflow.com/questions/3261557/why-is-windows-phone-7-emulator-so-slow-compared-to-um-iphone-os-emulator/3261644#3261644 –  Jul 25 '10 at 04:16
  • I've looked at it, but it's no help. Both versions I mention are running on the device, not in the simulator. Everything's perfect in the simulator. – John Smith Jul 25 '10 at 04:44
  • I am getting at this point: They are both different and that is why it is failing. –  Jul 25 '10 at 04:48
  • I was hoping for more enlightenment than that. I know that sometimes debug mode automatically clears variable on allocation for instance, but non-debug mode might not. Just saying it's different does not help. We all know that. WHERE is it different is the $99 question? – John Smith Jul 25 '10 at 04:56
  • @thyrgle -- He's failing on device in release mode but not debugger. The link you provided is talking about the emulation needed by the simulator. That's not relevant to this problem. – TechZen Jul 25 '10 at 05:22
  • Crashes on launch? Crashes a particular spot? Can't you still extract and symbolize your crash log off your device? – Nick Jul 25 '10 at 05:31
  • @TechZen: Well, my argument is that it explains that stuff works significantly different on the iPhone compared to the computer. And that, in a sense, explains why their are some stuff that work well in the simulator but not on the actual iPhone. –  Jul 25 '10 at 05:32
  • @Nick: it crashes at a particular point, trying to access a certain variable. I've done the stack trace and I cannot see how that variable has anything to do with anything. – John Smith Jul 25 '10 at 12:55
  • @John Smith -- You might not see how the variable causes a problem but maybe we can. A fresh set of eyes may see things you do not. The more info we have the better the chance we can spot something. – TechZen Jul 25 '10 at 13:04
  • yeah and what the crash is bad access etc. More info definitely needed. Minimally the stack trace but w/ code we'll have a better chance at helping. – Nick Jul 25 '10 at 17:29

2 Answers2

16

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.

Community
  • 1
  • 1
an yu
  • 451
  • 5
  • 8
  • The documentation you quoted says `Do not use this option [None] for shipping your executable`. But is that what you did? – Adam Johns Jul 12 '15 at 00:13
1

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?

bbum
  • 162,346
  • 23
  • 271
  • 359