I'm trying to fix the Qt exit hangup problem. For some reason, some Qt apps get stuck on exit and don't return to the shell prompt. This happens _after_ the main function has returned.
I have tried various things: Checking, that there are no GLContexts left out to dry (this is apparently not the case, and also if it was I would get the minigl dogwatch thing to complain, which it doesn't). I have checked that all objects get deleted (this is a really cumbersome task...).
My theory is, that it gets stuck in some decoponstructor function somewhere, but now the problem is, that I can't go through the entire Qt sources to check every single deconstructor to see if it happens there. If only we had a working debugger, then I could just fire it up and check where in the code I am stuck, but unfortunately this is not the case.
Does anyone have any idea how to solve this issue? I'm lost...
Does anyone have any idea how to solve this issue?
Not really, but you could try the tried-and-tested solution of disabling (large blocks of) functionality in the source code, until it stops misbehaving, so that you can gradually narrow-down the source of the problem.
Are you mixing pthreads with C++? The OS4 C++ libraries aren't thread safe, and this is one of problems you'll encounter. I had a similar issue when porting iperf, but rather than figure out the problem, I disabled threads. There isn't much point to debugging issues related to libstdc++ on OS4. They're not likely to be fixed any time soon.
In the meantime I think I have figured out what is wrong: Using dlopen to open plugins, but then Qt "forgets" to call dlclose() which makes it hang at exit. The case is very easily reproducable in small form: Just call dlopen() on some .so and exit without calling dlclose(), you will see, that the exe never returns to shell.
@Trev
Yeah, that's a problem. The current case doesn't use threads, though.
Just to add: When i port LodePaint (which use .so as plugins), and LodePaint itself (and .so plugins) are c++ ones, i always have crash on the dlclose(). I.e. all works fine, but on exit, always crash if i use dlclose() (and , of course, that all works on unixes).
So, for LodePaint i comment out all dlclose() in the whole programm, and after that i have no crashes (and all works fine). Dunno if it related to your problem or not, but just need to point imho that i also have some problems with dlclose() in c++ .
Btw, as we all know that pthread suck and have bugs for now (not only with QT , but i have notice it many times as well), it is possible to remove pthread dependeces at all from QT ? I mean that if it uses not very offten, and only there and theere, then it can be easy replaced on semaphores , almost without heavy changes.
For example, that how Fab change thread dependeces on semaphores in libCairo:
So for semaphores there is no destroy are need it looks like, and can be just skiped..
Dunno of course how all of this done for QT, maybe all of this not that easy as with cairo, and pthreads uses very heavy and in different conditions .. But maybe that brings some ideas as well :)
This may not be exactly the same thing, but I've seen something similar to this before, I had some probvlems with pthreads and constructors when working on the openEXR port (a dependency of blender and yafray) in my case i found that in some static c++ classes pthreads functions could be called before pthreads.libray was opened.
As there was no way to force the order in which static objects are constructed i had to rewrite my code to avoid the use of static objects. I think i arranged for the objects to be created on first attempted reference.
I wonder if in this case you objects are being destroyed after pthreads.library has been closed?
May be the solution would be to have static objects/classes to use their own instance of pthreads.library rather than relying on an externally opened instance ?
Note: that I don't know if pthreads.library allow sharing threads accross library instance (but that would be really dumb not to do this)
NOTE: this post is to try to confirm a potential problem on pthreads.library, to follow the kas1e explanation about this, maybe in my case, possible problem.
I have also a beta program that crash look like the same as the DSI posted above.
Someone know if pthread.library has been updated for the next update of AOS4 ?
In fact the crash looks very different than Alfkil's one. In yours the problem seems to lie in one of the thread (created from pthreads) when its trying to call a newlib function while in the SetProgressLabel() method of the class PostInfo. Most probable issue is that the thread is using a global variable which value changed or worst was disposed... At least it's what it seems to me looking at the crash log you are exposing.