[Kde-java] Installation Question

[Richard Dale]

On Saturday 01 February 2003 6:51 pm, Marco Ladermann wrote:
> On Samstag, 1. Februar 2003 18:53, Richard Dale wrote:
> > On Saturday 01 February 2003 3:12 pm, Marco Ladermann wrote:
> > > On Freitag, 31. Januar 2003 13:32, Richard Dale wrote:
>
> <snip/>
>
> > > Here are two versions of the messages spit out by the jvm (1.4) while
> > > running/aborting the same program two times:
> > >
> > > a)
> > > An unexpected exception has been detected in native code outside the
> > > VM. Unexpected Signal : 11 occurred at PC=0x400AE7CE
> > > Function=(null)+0x400AE7CE
> > > Library=/lib/libc.so.6
> > >
> > > b)
> > > An unexpected exception has been detected in native code outside the
> > > VM. Unexpected Signal : 11 occurred at PC=0x4002F0CD
> > > Function=__pthread_mutex_lock+0x1D
> > > Library=/lib/libpthread.so.0
>
> <snip/>
>
> > The bindings don't use threads, with the exception of the finalizer
> > thread calling the finalize() methods. Perhaps when the C++ instances are
> > deleted in the finalize() methods, it messes up the main thread.
>
> The problem is probably not the finalizer thread. Here is a little more of
> the dump (the rest is a list of the loaded libraries):
>
> Current Java thread:
>         at org.kde.qt.QApplication.newQApplication(Native Method)
>         at org.kde.qt.QApplication.<init>(QApplication.java:36)
>         at QtJava.main(QtJava.java:314)
>
> This looks like the dump occurs right away the first JNI call.
Well, at least the good news it is that the finalize code appears to be ok :). 
Is it that the java runtime and the multithreading Qt are using the 
__pthread_mutex_lock in some sort of incompatible way. That would explain why 
the non-multithreaded Qt lib worked ok. I've had a quick look at the 
qapplication.cpp source and there are quite a few references to threads and 
locking. I need to read the Qt docs and find out about how their threading 
stuff works..

-- Richard