Conflict between QTMovie / QTMovieView and custom C++ framework

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 appl开发者_如何学JAVAication 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.

Ryan, what does make you think there is a conflict between QTMovie and QTMovieView? Have you tried to exclude QTMovieView, does QTMovie play normally without it? You should be able to hear the sound at least. If the QTMovie is the issue, which I doubt, you could use QTMovieLayer instead.

Also, you said you used threads, QTMovie is a capricious thing, you always need to create it in the main thread. If you want to use it in another thread make sure you detached it successfully and attached to the new thread. In the new thread you need to call [QTMovie enterQTKitOnThread] or [QTMovie enterQTKitOnThreadDisablingThreadSafetyProtection] before you start doing anything with the movie. Also, [QTMovie exitQTKitOnThread] should be called after the movie has been detached from the thread and the thread is about to finish.

I trade QTMovieView as a screen only. For some simple apps, I also use it to handle everything like this:

[myQTMovieView setMovie:((QTMovie *)[QTMovie movieWithFile:file error:&error])];

[[myQTMovieView movie] stop];

[[myQTMovieView movie] autoplay];

so, in this way, you will never to init an QTMovie.