Aggressive optimization causes app to crash

As the subject line says:

  • runs fine under debugger regardless of optimization level
  • built app runs fine with default or moderate optimization
  • built app crashes with aggressive optimization

The crash log shows:
Crashed Thread: 0 Dispatch queue:

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000100000000

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x100000000:
__TEXT 000000010b479000-000000010b5d3000 [ 1384K] r-x/r-x SM=COW /Volumes/VOLUME/*/

Application Specific Information:
Performing @selector(performClick:) from sender XOJButton 0x60800014c290

Thread 0 Crashed:: Dispatch queue:
0 com.pkstys.aggressiveoptimizationtest 0x000000010b5bb5ea zlibModule.zlibUncompressMB%i8%ou4ou4 + 74
1 com.pkstys.aggressiveoptimizationtest 0x000000010b5b4ff8 Window1.Window1.PushButton1_Action%%o<Window1.Window1>o + 1032

Initially I thought it was the zlib decompressor that was crashing but zlibUncompressMB is just a wrapper to a newer decompressor method that actually does the decompression. It’s the simple wrapper method that crashes (if I call the real decompressor directly all is good).

You can see what I mean with this very simple project:

This is very worrisome if you can’t know which seemingly trivial parts of your code will or will not run correctly depending on compiler optimization level.

macOS, xojo 2021r2.1

Please make a feedback case.
I think it’s this line in assembler:

cmp qword [rbx], 0x0

and rbx is set before to

mov rbx, qword [_gCurrentException_1001bdf18]

and between that is the function call, which overwrites rbx register.
So the xojo compiler doesn’t tell LLVM to preserve register or to assume after function call, that it is overwritten.



So I was going to post a question asking 1) how reliable turning on optimizations in Xojo was, and 2) how significant those optimizations were.

Yes, I know the thing to do is to TRY them. However, my present application is just a lot of UI and not much computation, so I don’t even know if any level of optimization is worthwhile.

  • Default is a balance of size & speed
  • Moderate sacrifices speed for smaller size, takes longer than Default.
  • Aggressive sacrifices size for faster speed, takes longer than Moderate to build, sometimes significantly so.

FWIW, the Xojo IDE is built using Aggressive (at least it was 6 weeks ago) and it makes a huge difference in speed.

Hi Stephen,
Aggressive takes over 12 hours to compile my project which would be fine if the product ran correctly. As I reported, the built app crashes. I went to the trouble of creating a case and a reproducible project, and Christian tracked down the bug at the assembly level. The case is flagged as reproducible, but as far as I can see, not fixed. That was half a year ago.
So the answer to your Q1 is: not. And therefore Q2 is moot if you don’t known which part of your app will crash even tho it ran fine under debugger or normal optimization levels.

Hi again Stephen, inspired by your question i decided to try aggressive on another statistical app I wrote. This time there was no crash (at least not in the specific operation i tested, problem is you’d have to test your entire app every time to ensure the originally reported crash doesn’t bite you after aggressive), the operation in question is light on GUI and very heavy on large arrays and math ops. With regular the operation took 9.7hrs and with aggressive (that resulted in an .app pkg that was twice as large, an extra 400 MB) it took 8.2hrs. So about a 15% increase in speed.

@Peter_Stys – thanks for doing that test. It might even be worthwhile to compare performance in the latest 2022 release of Xojo to see if there’s any difference. I tend to think there won’t be a performance difference – otherwise the company would’ve promoted that fact.

Sometimes (as you know) only an algorithmic change will make a major performance difference.

For sure. My usual approach is to a) parallelize it to run on multiple cores and b) write the key parts in C, which in my experience is about 10x faster than Xojo (and i still don’t quite get why, especially for simple but massively repetitive operations. we’ve had this discussion many times on the forum). But of course this takes time and effort.