Any idea on this crash report?

General JUCE discussion
1

From what I can gather, crashes like this are caused by the order of static initializers. However, the class that it is crashing in doesn’t use any static objects as far as I can tell. Possibly an earlier static initializer is corrupting memory, causing it to crash here. Any tips on tracking this down?

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.my.plugin                	0x00000001537aaf18 0x153773000 + 229144 _GLOBAL__sub_I_GUI_EqControl.cpp (in Nexus) (GUI_EqControl.cpp:0)
1   dyld                          	0x0000000109e16592 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 506
2   dyld                          	0x0000000109e16798 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
3   dyld                          	0x0000000109e11bea ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 362
4   dyld                          	0x0000000109e10d73 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 133
5   dyld                          	0x0000000109e10e05 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 73
6   dyld                          	0x0000000109e03cb2 dyld::runInitializers(ImageLoader*) + 82
7   dyld                          	0x0000000109e0d3dc dlopen_internal + 607
8   libdyld.dylib                 	0x00007fff6570cd43 dlopen + 200
2

Hey @RolandMR,
Did you ever get the bottom of this one? I love the obscurity of “line:0” in the symbolicated report, which is exactly the same type of crash I have here! And of course we’ll investigate the static initialization stuff (but we’d been pretty careful about that knowing the “fiasco” issue for statics).

3

No. I think it has to do with using ‘static constexpr’ for variables in header files. I’ve never been able to reproduce it on my machine.

4

Thanks for this. Can you recall if these were simple types (int, float, etc) or more complex types that were constexpr? (It sounds like you just removed or refactored them in your case and this fixed it for whomever had the problem?)

5

Stumbled upon this post, because a tester reported the same type of crash.
I do use a lot of “static constexpr” in various headers. Should I remove all of them?
I like them, because they are very convenient for initialising e.g. floats or const char*. :smiley:

I am also wondering about the “static constexpr”. Are they only a problem, if they lead to the “static initialisation order fiasco”? Or are they generally a problem, even outside of a “static initialisation order fiasco”?

6

I am also dealing with this crash.

  • what Xcode version do you use?
    maybe the static constexpr is not supported well in some Xcode versions asking because I had some issues with static inline variables but in Win with MSVC.

  • Do you also experience it mainly with Logic host?

7

@alatar @MZ1 — we haven’t tracked this down precisely but we have seen report from both Logic Pro and Studio One. One of the workarounds (which sounds a bit odd) for Logic Pro is to: close Logic Pro, move the .component, reopen the project (which will fail without the plugin), close again, move the plugin back. Then it works afterwards! I wonder if forcing a full AU re-scan and resetting AU cache might help (and be less of PITA) but I haven’t been able to reproduce (the best kinds of bugs of course!).

8

Ah, interesting.
Yes, for us it was also in Logic.
And its a very rare and random problem for us (as far as I understand the testers).
Only happens very seldom.

9

This is rearing its head again… I assume this SO post is pointing to the potential problem with static constexpr in header files. And that there are different possible mitigations for:

  • C++17 (and later) - use inline; and
  • C++11/14 - use a constexpr function instead
10

Ask your users if they are also using an iLok. I seem to recall this was caused by iLoks corrupting memory.

11

Ah really, that’s interesting. Thanks

12

I guess I’m being too hopeful that you have any more info? (Given your wording: “seem to recall”)

13

Found it. For anyone else with this issue, it’s essentially described here:

We’re not sure yet if this is indeed the problem we’re having, nor whether the latest “iLok” 5.4.0 GM update fixes it if so