Apllication crashes only if it is compiled with -o0

Hallo,

I am co-author of an open source timetabling software. This software is running many years now on Windows, Linux and MacOS without crashing. So I compiled it with a lot of different compilers and it is always running fine. (with Windows mingw compiler, linux gcc compiler, ...) Now I compiled it on my new Mac and noticed and it is running fine as long as i am compiling it with -o1 or -o2 or -o3 or -ofast or -os or -oz.

But as soon as I compile it with -o0, then it crashes with MacOS. It doesn't crash if I compile with -o0 under Linux gcc compiler.

I tried to do a minimum example, but as soon as I remove some - in that situation unneeded - code, it is running fine again. So it looks like a memory limit in the compiler or something like that. I don't get it.

Any ideas how I can locate and/or fix the bug?

You can find the source here: https://lalescu.ro/liviu/fet/forum/index.php?topic=5729.0

I compiled with the latest clang version shipped with latest MacOS Sonoma.

I am also attaching the crash report log.

Thank you for your help.

appleLog.txt.log
Up vote post of Volker_D Down vote post of Volker_D
478 views
Posted by
Volker_D
Reply
Add a Comment

Replies

It's not unusual for optimisation settings to reveal bugs. You're lucky that the bug happens with lower optimisation, as that should be easier to debug than the other case. Can you trigger the bug in the debugger?

The stack trace seems clear to me. In thread 5, method Generate::randomSwap has hit a stack guard. One possibility is that you have run out of stack. Do you allocate large data structures on the stack? It does not seem to be a case of excessive recursion. The other possibility is that you are doing pointer arithmetic on a pointer to something on the stack, and you have gone out of bounds. Maybe someone else can extract some more clues from the stack log.

Posted by
endecotp
Post not yet marked as solved Up vote reply of endecotp Down vote reply of endecotp
Add a Comment

Thank you for your answer: Here some more information: I compiled with -g -o0, but it doesn't look like there is more infromation.

I used debugger "lldb" and it tells the stuff at the end of this mail. hmm.. doesn't like my source. The "randomSwap" function is sadly pretty large. I can't make it smaller without loosing speed, by speed is very important for timetabling, since it might run many hours to find solutions.

Is there an other way how I can debug it?

Here the lldb results:

vd@Mini-von-Volker fet-6.9.6_BENCHMARK % lldb /Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet (lldb) target create "/Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet" Current executable set to '/Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet' (arm64). (lldb) r Process 7992 launched: '/Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet' (arm64) 2023-10-21 21:19:11.202644+0200 fet[7992:30690] [default] CGSWindowShmemCreateWithPort failed on port 0 2023-10-21 21:19:11.219299+0200 fet[7992:30690] [default] CGSWindowShmemCreateWithPort failed on port 0 Process 7992 stopped

  • thread #10, stop reason = EXC_BAD_ACCESS (code=2, address=0x17014bff8) frame #0: 0x0000000189791e7c libsystem_pthread.dylib`___chkstk_darwin + 60

libsystem_pthread.dylib`: -> 0x189791e7c <+60>: ldur x11, [x11, #-0x8] 0x189791e80 <+64>: mov x10, sp 0x189791e84 <+68>: cmp x9, #0x1, lsl #12 ; =0x1000 0x189791e88 <+72>: b.lo 0x189791ea0 ; <+96> Target 0: (fet) stopped. (lldb)

Posted by
Volker_D
Up vote reply of Volker_D Down vote reply of Volker_D
Add a Comment