macOS: Crash on start when enabling Optimizations

[arximboldi]

macOS: Crash on start when enabling Optimizations

[arximboldi]

Hmmm, interesting, but it is hard to know if this is our problem with the few details you provided. A full stack trace would be nice. Also, to work around the problem, you could try using an alternative memory_policy.

[martinfinke]

Yeah, I understand..I have the case in the Xcode debugger right now; I don't know if I can save the stack trace, but here's the call stack in words 😬:

• We're on the com.apple.main-thread in _dyld_start
• It calls ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&)
• It calls __cxx_global_var_init.833(). This initializes the template <typename T, typename MP, bits_t B, bits_t BL> const rrbtree<T, MP, B, BL> rrbtree<T, MP, B, BL>::empty (in immer/detail/rbts/rbbtree.hpp:1274).
• The initializer calls node_t::make_inner_n(0u).
• In node.hpp:216, it executes the statement auto m = heap::allocate(sizeof_inner_n(n));.
• This calls into immer/heap/with_data.hpp:42, where it executes: auto p = base_t::allocate(size + sizeof(T), tags...);.
• This calls into immer/heap/unsafe_free_list_heap.hpp:64, where it executes: auto n = storage::head.data;.
• Then we're in the thread-local wrapper routine at the point in the screenshot above.

With IMMER_NO_FREE_LIST set to 1, the crash doesn't occur.

[arximboldi]

Hi Martin! It seems to me that you are running into a "static initialization order fiasco" [1]. The problem is that `ImageLoaderMachO` seems to be a static global that it is, when LTO is enabled, initialized before the thread local data that immer uses to optimize allocation using free lists. I think I might be able to fix that on the immer side, but in the meanwhile can workaround that by using this as the memory policy of the vector (second template parameter). immer::memory_policy< immer::heap_policy<immer::cpp_heap>, default_refcount_policy This may affect the performance of the vector. How much, it depends on the update patterns and you would have to measure yourself. [1] https://isocpp.org/wiki/faq/ctors#static-init-order Martin Finke <[email protected]> writes:

…

Yeah, I understand..I have the case in the Xcode debugger right now; I don't know if I can save the stack trace, but here's the call stack in words 😬: - We're on the `com.apple.main-thread` in `_dyld_start` - It calls `ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&)` - It calls `__cxx_global_var_init.833()`. This initializes the `template <typename T, typename MP, bits_t B, bits_t BL> const rrbtree<T, MP, B, BL> rrbtree<T, MP, B, BL>::empty` (in `immer/detail/rbts/rbbtree.hpp`:1274). - The initializer calls `node_t::make_inner_n(0u)`. - In `node.hpp:216`, it executes the statement `auto m = heap::allocate(sizeof_inner_n(n));`. - This calls into `immer/heap/with_data.hpp:42`, where it executes: `auto p = base_t::allocate(size + sizeof(T), tags...);`. - This calls into `immer/heap/unsafe_free_list_heap.hpp:64`, where it executes: `auto n = storage::head.data;`. - Then we're in the thread-local wrapper routine at the point in the screenshot above. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #37 (comment)

-- ∿∿∿ https://sinusoid.al ∿∿∿ https://sinusoid.es

[martinfinke]

Thanks, I'll use the workaround for now. Because it's about the allocation, it only affects the mutation performance, and not the iteration performance, right?

[arximboldi]

@martinfinke that is correct, access performance should not be affected. Updates might become slower, depending on the particular data patterns you use. I wouldn't worry too much about it. (Btw, IMMER_NO_FREE_LIST to 1 has the same effect as passing that policy explicitly, but in that case that is affecting all immer instances.)

[martinfinke]

Great, then performance is fine for now 👍 (I'll leave this open, you can keep it if you want to fix something about this)

[arximboldi]

Addressed by #42. @martinfinke can you check that this solves your problem once this lands master?

[martinfinke]

Just tested it with optimisations, I can confirm that this has solved the problem. Thanks so much! 👍

[arximboldi]

I am glad that worked! Please consider supporting the project on Patreon: https://www.patreon.com/sinusoidal