I’m experiencing an insane problem…
A simple Cocoa application with QTMovieView, in which a specific movie file is set or an application which loads and renders QTMovie manually works fine, however if I just link my custom Objective C++ framework, the application always hangs / deadlocks indefenitely right after first [QTMovie play] or [QTMovie autoplay] call…
My custom framework is pretty complex, but I can’t even imagine how it can be in a conflict with QTMovie since only static initialization logic is executed, the framework works perfectly fine with its container Cocoa application and there are no exceptions or signals, even valgrind fails to detect anything. There is, however, operator new overloading, but disabling it doesn’t help… Also it doesn’t matter from which thread the QTMovie is being accessed from – the result is always the same…
Changing compiler settings, synchronizing compiler settings with the framework settings have not effect, compiler settings by themselves do not seem to cause any problems.
Also, if I initialize QTMovie OR QTMovieView, load my framework dynamically and call the [QTMovie play] or [QTMovie autoplay] method, the thread it was called from will also deadlock…
Can somebody please help me understand, what can possibly cause this issue?!
Just from your description, it is hard to understand the exact sequence of calls that is going on. However, when I have seen freezes that match the general description of what you are doing in the past, they have usually been static initialisation problems. You mention that you only have static initialisation logic being executed, which to me makes this even more likely.
The problem is that file scope statics are not guaranteed to be initialised in any order. What happens, then, is that sometimes you can get differences in the order of initialisation depending on what libraries you link in.
So, if you have two objects A and B and B depends on A, you may find that most of the time the initialisers for A are called first and everything works, but then you link in a new library and suddenly B is scheduled first. Since it uses an uninitialised A, anything could happen, from accessing invalid/unmapped memory addresses to returning odd values used in if/else cases for weird program flow or strange container lookup, etc…
There are methods of removing these kinds of static initialisation issues. See this article on solving the static initialisation fiasco.