Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
35 user(s) are online (23 user(s) are browsing Forums)

Members: 0
Guests: 35

more...

Headlines

 
  Register To Post

Stuck in deconstructor??
Just can't stay away
Just can't stay away


See User information
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...

Go to top
Re: Stuck in deconstructor??
Home away from home
Home away from home


See User information
@alfkil Quote:
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.

Not sure if this is easy to do with QT though...

Author of the PortablE programming language.
I love using Amiga OS4.1
It is pitch black. You are likely to be eaten by a grue...
Go to top
Re: Stuck in deconstructor??
Just can't stay away
Just can't stay away


See User information
Yeah, the good old "source code massacre" solution

I will see what I can do, only it is pretty impossible with Qt since so many things are tied together.

Go to top
Re: Stuck in deconstructor??
Quite a regular
Quite a regular


See User information
IF you had "a proper debugger", you would use it to add breakpoints, then examine data at the point, right?

So just add some IExec->DebugPrintF() statements at the places where you would put breakpoints, and go from there.

cheers
tony
Go to top
Re: Stuck in deconstructor??
Just popping in
Just popping in


See User information
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.

Go to top
Re: Stuck in deconstructor??
Home away from home
Home away from home


See User information
You could try the following "nasty hack"

When the task has hung and not returned to the shell, start ranger (or scout) find the task in the task list and get it's address.


Then do

sys:system/GrimReaper <taskaddres>

this will cause a "crash" which brings up the GR and you can then get a stack trace.

Once you've done this your system *will* be unstable and so save the stack trace and reboot.

Then use the stack trace as normal to find the place in the program that has hung.



Go to top
Re: Stuck in deconstructor??
Just can't stay away
Just can't stay away


See User information
@broadblues

Nice hack there, I will try it out later .

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.

Go to top
Re: Stuck in deconstructor??
Home away from home
Home away from home


See User information
@alfkil

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++ .

Go to top
Re: Stuck in deconstructor??
Just can't stay away
Just can't stay away


See User information
@kas1e

Hmm... That's odd!

@thread

Apparently it wasn't the dlclose() problem either, so with help from broadblues methos I was able to get a stack trace from the hung up process:

Stack trace:
    
native kernel module kernel+0x0000f4d0
    native kernel module kernel
+0x00034114
    pthreads
.library:_impl_cond_destroy()+0xB4 (section 1 0x2ad4)
    
libpthread.so:pthread_cond_destroy()+0x3C (section 8 0x1318)
    
libQtCore.so.4.7.0:_ZN14QWaitConditionD1Ev()+0x48 (section 10 0x7078c)
    
libQtCore.so.4.7.0:_ZN14QThreadPrivateD0Ev()+0x150 (section 10 0x64a18)
    
libQtCore.so.4.7.0:_ZN21QScopedPointerDeleterI11QObjectDataE7cleanupEPS0_()+0x40 (section 10 0x26ab18)
    
libQtCore.so.4.7.0:_ZN14QScopedPointerI11QObjectData21QScopedPointerDeleterIS0_EED1Ev()+0x48 (section 10 0x34bfdc)
    
libQtCore.so.4.7.0:_ZN7QObjectD2Ev()+0x9F8 (section 10 0x348a4c)
    
libQtCore.so.4.7.0:_ZN7QThreadD2Ev()+0x244 (section 10 0x636a8)
    
libQtCore.so.4.7.0:_ZN14QAdoptedThreadD0Ev()+0x144 (section 10 0x63c24)
    
libQtCore.so.4.7.0:_ZN11QThreadDataD1Ev()+0x1C8 (section 10 0x6447c)
    
libQtCore.so.4.7.0:_ZN11QThreadData5derefEv()+0x70 (section 10 0x64898)
    
libQtCore.so.4.7.0:_ZN7QObjectD2Ev()+0x9D4 (section 10 0x348a28)
    
libQtCore.so.4.7.0:_ZN6QTimerD1Ev()+0x158 (section 10 0x35eb14)
    
libQtGui.so.4.7.0:_Z41__static_initialization_and_destruction_0ii()+0xA4 (section 10 0x1aa4a0)
    
libQtGui.so.4.7.0:_GLOBAL__D__ZN14QWidgetPrivate12mouseGrabberE()+0x40 (section 10 0x1aa510)
    
libQtGui.so.4.7.0:__shlib_call_destructors()+0x3C (section 10 0xc8)
    
native kernel module elf.library.kmod+0x00007e2c
    native kernel module newlib
.library.kmod+0x00001e40
    native kernel module newlib
.library.kmod+0x00002b98
    native kernel module newlib
.library.kmod+0x00002d5c
    menus
:_start()+0x170 (section 8 0x170)
    
native kernel module dos.library.kmod+0x0001b524
    native kernel module kernel
+0x00036290
    native kernel module kernel
+0x00036310


So it seems, that it is stuck on pthread_cond_destroy(). Under what conditions could this happen? Also, I'm really puzzled by the line that says

_GLOBAL__D__ZN14QWidgetPrivate12mouseGrabber etc

It is defined like this

class QWidgetPrivate : bla
{
...bla ...

static QWidget *mouseGrabber;

}

And later on

QWidgetPrivate::mouseGrabber = 0;

Go to top
Re: Stuck in deconstructor??
Home away from home
Home away from home


See User information
@alkil

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:

Quote:

#if CAIRO_NO_MUTEX

/* No mutexes */

typedef int cairo_mutex_impl_t;

# define CAIRO_MUTEX_IMPL_NO 1
# define CAIRO_MUTEX_IMPL_INITIALIZE() CAIRO_MUTEX_IMPL_NOOP
# define CAIRO_MUTEX_IMPL_LOCK(mutex) CAIRO_MUTEX_IMPL_NOOP1(mutex)
# define CAIRO_MUTEX_IMPL_UNLOCK(mutex) CAIRO_MUTEX_IMPL_NOOP1(mutex)
# define CAIRO_MUTEX_IMPL_NIL_INITIALIZER 0

#elif __MORPHOS__

# include <exec/semaphores.h>
# include <proto/exec.h>
# include <clib/debug_protos.h>

typedef struct SignalSemaphore cairo_mutex_impl_t;

# define CAIRO_MUTEX_IMPL_MORPHOS 1
# define CAIRO_MUTEX_IMPL_LOCK(mutex) ObtainSemaphore(&(mutex))
# define CAIRO_MUTEX_IMPL_UNLOCK(mutex) ReleaseSemaphore(&(mutex))
# define CAIRO_MUTEX_IMPL_INIT(mutex) InitSemaphore(&(mutex))
# define CAIRO_MUTEX_IMPL_NIL_INITIALIZER {}
# define CAIRO_MUTEX_IMPL_FINI(mutex) CAIRO_MUTEX_IMPL_NOOP


#elif HAVE_PTHREAD_H /*******************************************************/

# include <pthread.h>

typedef pthread_mutex_t cairo_mutex_impl_t;

# define CAIRO_MUTEX_IMPL_PTHREAD 1
#if HAVE_LOCKDEP
/* expose all mutexes to the validator */
# define CAIRO_MUTEX_IMPL_INIT(mutex) pthread_mutex_init (&(mutex), NULL)
#endif
# define CAIRO_MUTEX_IMPL_LOCK(mutex) pthread_mutex_lock (&(mutex))
# define CAIRO_MUTEX_IMPL_UNLOCK(mutex) pthread_mutex_unlock (&(mutex))
#if HAVE_LOCKDEP
# define CAIRO_MUTEX_IS_LOCKED(mutex) LOCKDEP_IS_LOCKED (&(mutex))
# define CAIRO_MUTEX_IS_UNLOCKED(mutex) LOCKDEP_IS_UNLOCKED (&(mutex))
#endif
# define CAIRO_MUTEX_IMPL_FINI(mutex) pthread_mutex_destroy (&(mutex))
#if ! HAVE_LOCKDEP
# define CAIRO_MUTEX_IMPL_FINALIZE() CAIRO_MUTEX_IMPL_NOOP
#endif
# define CAIRO_MUTEX_IMPL_NIL_INITIALIZER PTHREAD_MUTEX_INITIALIZER

#elif defined(HAVE_WINDOWS_H) || defined(_MSC_VER) /*************************/


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 :)


Go to top
Re: Stuck in deconstructor??
Just can't stay away
Just can't stay away


See User information
Apparently removing every reference to pthreads_cond_destroy() "solved" the problem...

That is horrible!

Go to top
Re: Stuck in deconstructor??
Home away from home
Home away from home


See User information
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?

Go to top
Re: Stuck in deconstructor??
Quite a regular
Quite a regular


See User information
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)

Back to a quiet home... At last
Go to top
Re: Stuck in deconstructor??
Quite a regular
Quite a regular


See User information
Hello,

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 ?


Stack trace:
native kernel module newlib.library.kmod+0x000036e0
native kernel module newlib.library.kmod+0x00029cd0
nzbget:_ZN8PostInfo16SetProgressLabelEPKc()+0x44 (section 1 @ 0x1e10c)
nzbget:_ZN16PrePostProcessor17UpdateParProgressEv()+0xB0 (section 1 @ 0x544a4)
nzbget:_ZN16PrePostProcessor14PostParChecker14UpdateProgressEv()+0x28 (section 1 @ 0x54774)
nzbget:_ZN10ParChecker3RunEv()+0x540 (section 1 @ 0x48e98)
nzbget:_ZN6Thread14thread_handlerEPv()+0x70 (section 1 @ 0x84330)
pthreads.library:run()+0x278 (section 1 @ 0x4134)
pthreads.library:ThreadCode()+0x35C (section 1 @ 0x44dc)
native kernel module dos.library.kmod+0x0001b524
native kernel module kernel+0x00036290
native kernel module kernel+0x00036310

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: Stuck in deconstructor??
Home away from home
Home away from home


See User information
@MrodFR

As i can see, in your example also C++ was used, but crash are pretty different that those ones which i have and which alfkil have.

When that program about which you say compiled without pthread support all is fine ?

Go to top
Re: Stuck in deconstructor??
Quite a regular
Quite a regular


See User information
@Mrodfr

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.

Back to a quiet home... At last
Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project