jamvm-general — General discussion of the Jam Virtual Machine.

[Jamvm-general] jamVM to MINIX

[John S. <db...@gm...>]

Hi all,

For some reason I need to port jamVM to MINIX, given that I'm CS student on
third year, could somebody point me to some literature or documentation
that would help me to better understand code, and what parts/files should
be ported? Also MINIX doesn't support POSIX threads, so is it possible to
strip jamVM of its java level thread support so it could be executed in
just one thread (process).

Thanks in advance,
John

[Jamvm-general] JogAmp JOGL angelesgl2es1 applet runs using JamVM!

[Xerxes R. <xe...@za...>]

Thank you Robert for the amazing and stable JamVM!

Currently only JamVM is able to run:
http://jogamp.org/deployment/jogamp-current/jogl-demos/jogl-newt-applet-runner-angelesgl2es1.html
In combination with OpenJDK 6/7 and IcedTea-web 1.2/1.3.

Issue with Hotspot:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1218

Issue with Cacao:
http://c1.complang.tuwien.ac.at/pipermail/cacao/2012-November/001473.html

Issue with Avian:
https://groups.google.com/forum/?fromgroups=#!topic/avian/eTw3Y0de0Ls

Cheers
Xerxes

[Jamvm-general] JamVM + LWJGL + OpenJDK running 60fps 1080p on RaspberryPi!

[Xerxes R. <xe...@za...>]

And yes Blocky is running 60fps 1080p using #JamVM + #OpenJDK + #LWJGL + #Rasbian #armhf on my #RaspberryPi !

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=22341&p=212058

Cheers
Xerxes

[Jamvm-general] Avoid version in libjvm.so SONAME to prevent OpenJDK 7 "couldn't open libjava.so" runtime error.

[Xerxes R. <xe...@za...>]

Hi Robert!

About a year ago I encountered an odd bug:
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/850433 - java -jamvm fails to run; couldn't open libjava.so
today we managed to track it down inside the IcedTea project.
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1155

# All the IcedTea build-bots was testing using --enable-jamvm
building icedtea 7 with --enable-jamvm == work
# While the Debian and Ubuntu package builder used --with-additional-vms=jamvm
building icedtea 7 with --with-additional-vms=jamvm == triggers this bug

# testcase that fail:
# ../icedtea7-2.3/configure --with-additional-vms=jamvm
./j2sdk-image-additional-vms-jamvm/bin/java -jamvm -version
Error initialising natives: couldn't open libjava.so: use -verbose:jni for more information
Error initialising VM (initialiseNatives)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

# testcase that work:
# ../icedtea7-2.3/configure --enable-jamvm
./j2sdk-image-enable-jamvm/bin/java -version
java version "1.7.0_07"
IcedTea7 Runtime Environment (2.3.2+re7117fcb33ed) (Ubuntu build 1.7.0_07-b30)
JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)


Inspection revealed that the libjava.so got linked differently depending if it was linked against the Hotspot Server libjvm.so or the JamVM libjvm.so

ldd j2sdk-image-additional-vms-jamvm/jre/lib/i386/libjava.so
	libjvm.so => not found
...

ldd j2sdk-image-enable-jamvm/jre/lib/i386/libjava.so
	libjvm.so.0 => not found
...

All in all the bug turned out to be that the Hotspot server/client libjvm.so used a different, non-versioned internal SONAME, compared to the versioned JamVM libjvm.so SONAME .

objdump -x icedtea7-2.3-server-jamvm/openjdk.build/j2sdk-image/jre/lib/i386/server/libjvm.so | grep SONAME
  SONAME               libjvm.so
objdump -x icedtea7-2.3-server-jamvm/openjdk.build/j2sdk-image/jre/lib/i386/jamvm/libjvm.so | grep SONAME
  SONAME               libjvm.so.0

By telling libtool to skip adding a SONAME versioning number to the JamVM libjvm.so enabled a Hotspot Server linked libjava.so to locate the JamVM libjvm.so

Cheers from Xerxes and Matthias

Patch by Matthias Klose do...@ub...

diff --git a/src/Makefile.am b/src/Makefile.am
index e5c8020..5fbdd7c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -41,6 +41,7 @@ jamvm_SOURCES = jam.c
 libjvm_la_SOURCES =

 jamvm_LDADD = libcore.la
+libjvm_la_LDFLAGS = -avoid-version
 libjvm_la_LIBADD = libcore.la
 libcore_la_LIBADD = interp/libinterp.la os/@os@/@arch@/libnative.la \
                     os/@os@/libos.la classlib/@classlib@/libclasslib.la

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Robert Lougher wrote:

> As promised, I instrumented the VM, and confirmed my hypothesis.
> Without knowing the details of QtJambi's JNI code, I can't say it's
> definitely a bug in QtJambi, but a thread is being attached to the VM
> via AttachCurrentThread{AsDaemon}().  This thread is then exiting
> without calling DetachCurrentThread().  This breaks the JNI rules
> (http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/invocation.html):

FWIW the section you cite does not exist in the JavaSE 5 version of the 
same document at:

http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html


While I accept the JavaSE 6 document maybe a clarification of the 
intention of previous specifications if the scenario were to be allowed 
by JDK5 specification it should be noted in a JDK5 erratum. Can you cite 
such an erratum ?


The QtJambi project only asks for and requires JNI_VERSION_1_4 so it 
would be expected the implementation be compliant with the terms of that 
JNI version (plus erratum).  While the project claims support for Java5+ 
there are some things we do inside the project to make life easier for 
porting to 1.4 because some people were using 1.4 on ARM CPUs with a 
custom build for QtJambi since that support for them is just a recompile 
away.


However this doesn't mean we shouldn't call Detach I am just rebutting 
to claim that JNI rules are being broken on this matter.  It is my 
intention to be calling Detach as soon as possible with future releases.

Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Robert Lougher wrote:
> On 2 July 2012 10:06, Darryl Miles<dar...@ne...>  wrote:
>> There is in the QtJambi project a call to:
>>
>> src/cpp/qtjambi/qtjambi_core.cpp:311
>>    if (vm->AttachCurrentThreadAsDaemon((void **) (void *) (&env), 0)<  0) {
>>
>>
>> That does not have a counterpart action to Detach.
>>
>
> There is only one detach function (DetachCurrentThread), which is used
> to detach both daemon and non-daemon threads

Sure.

There is no counterpart action to Deatch in the QtJambi code base.


Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Robert L. <rob...@gm...>]

Hi Darryl,

On 2 July 2012 10:06, Darryl Miles <dar...@ne...> wrote:
>
>
> Thanks for looking into the JamVM side.
>
>
> There is in the QtJambi project a call to:
>
> src/cpp/qtjambi/qtjambi_core.cpp:311
>   if (vm->AttachCurrentThreadAsDaemon((void **) (void *) (&env), 0) < 0) {
>
>
> That does not have a counterpart action to Detach.
>

There is only one detach function (DetachCurrentThread), which is used
to detach both daemon and non-daemon threads (i.e. those attached with
either AttachCurrentThread or AttachCurrentThreadAsDaemon).  A
DetachCurrentThreadAsDaemon counterpart is not needed as the VM
obviously knows what type the thread is, and it would be worse than
having just the one, as code could then call the wrong detach
function.  It would perhaps have been better if the daemon status had
been a parameter to AttachCurrentThread, as this would not have lead
to confusion.

Rob.

>
> Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Thanks for looking into the JamVM side.


There is in the QtJambi project a call to:

src/cpp/qtjambi/qtjambi_core.cpp:311
   if (vm->AttachCurrentThreadAsDaemon((void **) (void *) (&env), 0) < 0) {


That does not have a counterpart action to Detach.

I think it should be possible to write a Qt signal hook to be called on 
QThread termination() to allow a callback into JNI to detach.  By virtue 
of it having the signal connected to a Detach handler function means it 
was Attached in this way.

So I will investigate this matter from the QtJambi side.



Robert Lougher wrote:
> On 28 June 2012 01:31, Darryl Miles<dar...@ne...>  wrote:
> On a second QUIT the easiest solution is to walk the thread stacks
> without attempting to suspend the threads.  This could crash the VM if
> the stack is changing underneath, but it's an emergency mode.  In this
> case, the thread has died, and its Java stack is empty.

It is possible to install a SIGSEGV handler and have it change the CPU 
hardware Program Counter to jump a memory location to resume execution 
(like Windows SEH) also like a longjump.

So it would even be possible to access illegal memory without anything 
bad happening (except performance loss of context switching and CPU 
hardware exception handlers running).

The code doing the dumping would need to defend itself against 
interpreting garbage data and ending up in an infinite loop.  But 
providing the information was marked as unreliable whatever it output 
would still be useful in diagnosis.



> I hacked in a workaround, which is to ignore the thread if the signal
> fails with ESRCH, which indicates an invalid thread ID.  This enables
> the tests to complete, finishing in just over 4 minutes.  I've ran the
> tests completely through 10 times without any hangs.

I did try to use pthread_kill() in this way myself but could not get it 
to make a difference in the 30 mins I hacked on the matter last week.



> As I said, this is a hack which I'm not very happy with as it
> shouldn't be necessary with well behaved JNI code.  However, I may
> tidy it up and leave it in as it makes the code more resilient to
> potential errors.

I agree resilience is a good goal.  JNI is hard to verify all the rules 
as being followed.

So getting a loud warning would be kind of useful to report with 
-Xcheck:jni enabled.



Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Robert L. <rob...@gm...>]

Hi Darryl,

On 28 June 2012 01:31, Darryl Miles <dar...@ne...> wrote:

> It is still useful to have some kind of output (missing any unreliable
> information) than nothing at all.
>
>
> Maybe sending a -QUIT will cause the thread dump to wait until all threads
> are suspended.
>
> Maybe sending a 2nd -QUIT (while the previous -QUIT is waiting for all
> threads to suspend) should cause it to dump whatever reliable information it
> can, listing the one or more threads that did not suspend with whatever
> information is known and reliable.  Having dumped the data the signal
> handler would reset and the next -QUIT would go back to normal of waiting
> for all threads to suspend.
>
>

On a second QUIT the easiest solution is to walk the thread stacks
without attempting to suspend the threads.  This could crash the VM if
the stack is changing underneath, but it's an emergency mode.  In this
case, the thread has died, and its Java stack is empty.

As promised, I instrumented the VM, and confirmed my hypothesis.
Without knowing the details of QtJambi's JNI code, I can't say it's
definitely a bug in QtJambi, but a thread is being attached to the VM
via AttachCurrentThread{AsDaemon}().  This thread is then exiting
without calling DetachCurrentThread().  This breaks the JNI rules
(http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/invocation.html):

"A native thread attached to the VM must call DetachCurrentThread() to
detach itself before exiting. A thread cannot detach itself if there
are Java methods on the call stack."

In other VMs this may not lead to a catastrophic failure, but in
JamVM, we end up with a dead thread on the thread-list.  The
suspension code sends it a signal, and then hangs waiting for it to
suspend (which it won't as it's dead).

I hacked in a workaround, which is to ignore the thread if the signal
fails with ESRCH, which indicates an invalid thread ID.  This enables
the tests to complete, finishing in just over 4 minutes.  I've ran the
tests completely through 10 times without any hangs.

As I said, this is a hack which I'm not very happy with as it
shouldn't be necessary with well behaved JNI code.  However, I may
tidy it up and leave it in as it makes the code more resilient to
potential errors.

Rob.

> Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Robert Lougher wrote:
>>> We push the GC in the QtJambi unit tests to attempt to cause behavior and verify the implementation.

It is still useful to have some kind of output (missing any unreliable 
information) than nothing at all.


Maybe sending a -QUIT will cause the thread dump to wait until all 
threads are suspended.

Maybe sending a 2nd -QUIT (while the previous -QUIT is waiting for all 
threads to suspend) should cause it to dump whatever reliable 
information it can, listing the one or more threads that did not suspend 
with whatever information is known and reliable.  Having dumped the data 
the signal handler would reset and the next -QUIT would go back to 
normal of waiting for all threads to suspend.


Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Robert L. <rob...@gm...>]

On 26 June 2012 18:50, Xerxes Rånby <xe...@za...> wrote:
> Note that this thread id 8 is the only thread that still got thread->suspend_state==0 .
>
> I will try locate which linux/pthread that corresponds to this JamVM thread id 8 and check what it is doing.
>

OK, I have reproduced a hang, and it is identical to what Xerxes
reports here (waiting for thread id 8).  The interesting thing is that
although the thread is on the thread list, no thread corresponding to
it seems to exist.  This can't happen for threads created within Java,
as they are always removed from the thread list on exit.  It can only
happen when a thread is created outside the VM, is attached via JNI,
and then dies without being detached.

I'll turn on some debug traces tomorrow to track thread attach/detach.

Thanks,
Rob.

> Cheers
> Xerxes

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Robert L. <rob...@gm...>]

On 26 June 2012 18:50, Xerxes Rånby <xe...@za...> wrote:
> 2012-06-26 18:49, Darryl Miles skrev:
>> Xerxes Rånby wrote:
>>> If I attach gdb I then notice that JamVM is stuck in a loop waiting for all threads to suspend before running garbage collection.
>>
>> Is it possible that is is waiting for all threads (including those that have entered JNI and maybe suspended/sleeping/waiting in C/C++) ?
>>
>> Is there already a mechanism that knows a thread is currently in JNI and also every JNI method has a check to wait behind a GC (is one is pending or in progress) and/or possibly wake up the GC thread waiting for the indication to start.
>>
>> I guess at the moment from the 100% CPU there is no such wait/sleep mechanism for the GC itself to start.  Maybe it should spin a certain number of times, before setting up state so that the threads causing it not to be able to start will need to notify (i.e. wake) the GC thread up when they get to a safe-point/check-point.  The GC thread then checks one last time before itself going to sleep.
>>
>>
>>
>> Can you get a thread dump from JamVM, I tried kill -QUIT but did not see any output.
>
> I have generated a thread dump by walking the self and main_thread pointers using ddd see attached screen-shot:
>
> GC running at linux/pthread 10:
> The GC is spinning and waiting for JamVM thread id 8 to suspend.
> Note that this thread id 8 is the only thread that still got thread->suspend_state==0 .
>
> I will try locate which linux/pthread that corresponds to this JamVM thread id 8 and check what it is doing.
>

Interesting screen shot.  The crucial bit of information missing is
the backtrace from thread 8 (JamVM thread id).  As there's not many
threads, it should be possible to get backtraces from all of them.  It
will be easy to discount those that are in a blocking critical section
(suspend_state = 3, probably in a mutex), and the one within the
suspend loop (suspend_state = 1).

JamVM uses a mixture of signals (low latency) and safe-point style
self-suspension.  The thread within suspendAllThreads() is waiting for
thread id 8 to either self-suspend, or it is waiting for it to suspend
within the signal handler (if it was signalled).

My guess is that it was signalled, and for some reason it hasn't
responded.  It is possibly related to futexs, and their use in glibc
in malloc and friends, which I think is relatively recent.  The
suspension code was heavily stress-tested in 2007, after a user
reported deadlocks (many threads, running continuously for weeks).
During this time I eliminated all non-reentrant code within the
suspension/GC code.

> The same bug triggers for kill -QUIT since a thread dump also pre-require that all JamVM threads have reached the suspended state.

A thread must be suspended in order to walk its stack.

Rob.

>
> Cheers
> Xerxes
>
>
>>
>> We push the GC in the QtJambi unit tests to attempt to cause behavior and verify the implementation.
>>
>>
>>
>> Darryl
>

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Xerxes R. <xe...@za...>]

2012-06-26 18:49, Darryl Miles skrev:
> Xerxes Rånby wrote:
>> If I attach gdb I then notice that JamVM is stuck in a loop waiting for all threads to suspend before running garbage collection.
> 
> Is it possible that is is waiting for all threads (including those that have entered JNI and maybe suspended/sleeping/waiting in C/C++) ?
> 
> Is there already a mechanism that knows a thread is currently in JNI and also every JNI method has a check to wait behind a GC (is one is pending or in progress) and/or possibly wake up the GC thread waiting for the indication to start.
> 
> I guess at the moment from the 100% CPU there is no such wait/sleep mechanism for the GC itself to start.  Maybe it should spin a certain number of times, before setting up state so that the threads causing it not to be able to start will need to notify (i.e. wake) the GC thread up when they get to a safe-point/check-point.  The GC thread then checks one last time before itself going to sleep.
> 
> 
> 
> Can you get a thread dump from JamVM, I tried kill -QUIT but did not see any output.

I have generated a thread dump by walking the self and main_thread pointers using ddd see attached screen-shot:

GC running at linux/pthread 10:
The GC is spinning and waiting for JamVM thread id 8 to suspend.
Note that this thread id 8 is the only thread that still got thread->suspend_state==0 .

I will try locate which linux/pthread that corresponds to this JamVM thread id 8 and check what it is doing.

The same bug triggers for kill -QUIT since a thread dump also pre-require that all JamVM threads have reached the suspended state.

Cheers
Xerxes


> 
> We push the GC in the QtJambi unit tests to attempt to cause behavior and verify the implementation.
> 
> 
> 
> Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Xerxes Rånby wrote:
> If I attach gdb I then notice that JamVM is stuck in a loop waiting for all threads to suspend before running garbage collection.

Is it possible that is is waiting for all threads (including those that 
have entered JNI and maybe suspended/sleeping/waiting in C/C++) ?

Is there already a mechanism that knows a thread is currently in JNI and 
also every JNI method has a check to wait behind a GC (is one is pending 
or in progress) and/or possibly wake up the GC thread waiting for the 
indication to start.

I guess at the moment from the 100% CPU there is no such wait/sleep 
mechanism for the GC itself to start.  Maybe it should spin a certain 
number of times, before setting up state so that the threads causing it 
not to be able to start will need to notify (i.e. wake) the GC thread up 
when they get to a safe-point/check-point.  The GC thread then checks 
one last time before itself going to sleep.



Can you get a thread dump from JamVM, I tried kill -QUIT but did not see 
any output.



We push the GC in the QtJambi unit tests to attempt to cause behavior 
and verify the implementation.



Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Xerxes R. <xe...@za...>]

2012-06-21 17:43, Darryl Miles skrev:
> Robert Lougher wrote:
>> On 21 June 2012 15:34, Darryl Miles<dar...@ne...>  wrote:
>>> Robert Lougher wrote:
>>>
>>> When using 'strace' on the JamVM it was sleeping on FUTEX.
>>>
>>> I tried to kill -QUIT a few times and it seemed to then eat 100% CPU on a
>>> core, I did not see any Thread Dump output in logs or console and after
>>> allowing it a few minutes at 100% CPU I 'kill -9'.  Maybe it was already
>>> eating CPU.
>>>
>>>
>>> So what things might I do to investigate the matter further.
>>
>> I'd be interested in running the tests myself.  Are there any instructions?
>>
>> The fix allows the example that Xerxes posted to start up.  I've ran
>> all the demos in that example, and they all seem to work OK.
>
...
>
> execute 'ant tests.run' to run the tests
>
> ## Be ready to kill the JamVM java process if it appears to be stuck
> ##  do this around 8 times and eventually the tests will finish and
> ##  a report get produced.
>

I have been able to reproduce this bug.

First I applied the following patch on JamVM to let it ignore the -Xrs and -Xcheck:jni options passed by the qt-jambi testsuite.

Index: jamvm/src/init.c
===================================================================
--- jamvm.orig/src/init.c       2011-10-03 15:14:14.153644152 +0200
+++ jamvm/src/init.c    2012-06-25 17:00:24.552557251 +0200
@@ -176,10 +176,16 @@
     {"-dsa",     OPT_NOARG},
     {"-Xint",    OPT_NOARG},
     {"-Xcomp",   OPT_NOARG},
+    {"-Xcheck:jni", OPT_NOARG},
     {"-Xbatch",  OPT_NOARG},
     {"-Xmixed",  OPT_NOARG},
+    {"-Xrs",     OPT_NOARG},
     {"-ea",      OPT_NOARG | OPT_ARG},
     {"-da",      OPT_NOARG | OPT_ARG},
+    {"-enableassertions",        OPT_NOARG | OPT_ARG},
+    {"-disableassertions",       OPT_NOARG | OPT_ARG},
+    {"-enablesystemassertions",  OPT_NOARG},
+    {"-disablesystemassertions", OPT_NOARG},
     {NULL, 0}
 };


While running the ant tests.run I did like Darryl stuck waiting for FUTEX when the junit tests reaches the following point:
    [junit]
    [junit] Loading library: 'libcom_trolltech_qt_network.so.1'...
    [junit]  - using deployment spec at /home/xranby/libqtjambi-snapshot-0.0~201205301429+bzr3381~precise1/build/platform-output/lib/libcom_trolltech_qt_network.so.1
    [junit]  - ok!
    [junit]
    [junit] QThreadManagerUtils.releaseNativeResources()=0
    [junit] QThreadManagerUtils.releaseNativeResources()=0
    [junit] QThreadManagerUtils.releaseNativeResources()=0
    [junit] QThreadManagerUtils.releaseNativeResources()=0
    [junit] QThreadManagerUtils.releaseNativeResources()=0
    [junit] QThreadManagerUtils.releaseNativeResources()=0
    [junit] QThreadManagerUtils.releaseNativeResources()=0
    [junit] QThreadManagerUtils.releaseNativeResources()=0


If I attach gdb I then notice that JamVM is stuck in a loop waiting for all threads to suspend before running garbage collection.

(gdb) thread 10
[Switching to thread 10 (Thread 0xb7790b40 (LWP 8831))]
#0  0x00e8c1b2 in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0  0x00e8c1b2 in ?? () from /lib/ld-linux.so.2
#1  0x00290aac in sched_yield () from /lib/i386-linux-gnu/libc.so.6
#2  0x00afadc9 in suspendAllThreads (self=0xb46ea0) at thread.c:928
#3  0x00ae9a26 in gc0 (mark_soft_refs=1, compact=0) at alloc.c:1609
#4  0x00ae9c92 in gc1 () at alloc.c:1660
#5  0x00b163e4 in JVM_GC () at jvm.c:242
#6  0x0075eb97 in Java_java_lang_Runtime_gc ()
   from /usr/lib/jvm/java-6-openjdk-i386/jre/lib/i386/libjava.so
#7  0x00b13e49 in __V (class=0x98b6e710, mb=0xb6ee4f34, ostack=0x98a0d5e0)
    at jni-stubs.c:517
#8  0x00b099b3 in executeJava () at interp.c:2231
#9  0x00af86cd in invoke (ob=0x98b9ffd8, mb=0x93bdeebc, arg_array=0x991d94a0,
    param_types=0x98dcf998) at reflect.c:581
#10 0x00af89e6 in methodInvoke (ob=0x98b9ffd8, mb=0x93bdeebc,
    args_array=0x991d94a0, ret_type=0x98c0aed8, param_types=0x98dcf998,
    no_access_check=1, depth=0) at reflect.c:694
#11 0x00b1bb05 in invokeMethod (reflect_ob=0x98dd1078, ob=0x98b9ffd8,
    args_array=0x991d94a0) at reflect.c:255
#12 0x00b19abb in JVM_InvokeMethod (env=0xb2f900, method=0x98dd1078,
    obj=0x98b9ffd8, args0=0x991d94a0) at jvm.c:2635
#13 0x00765a42 in Java_sun_reflect_NativeMethodAccessorImpl_invoke0 ()
   from /usr/lib/jvm/java-6-openjdk-i386/jre/lib/i386/libjava.so
#14 0x00b14871 in static_JI_L (class=0x98ddd4d0, mb=0x93c119e4,

Breakpoint 1, suspendAllThreads (self=0xb46ea0) at thread.c:928
928	            sched_yield();
(gdb) s
924	        while(thread->suspend_state != SUSP_BLOCKING &&
(gdb) s

Breakpoint 1, suspendAllThreads (self=0xb46ea0) at thread.c:928
928	            sched_yield();
(gdb) s
924	        while(thread->suspend_state != SUSP_BLOCKING &&
(gdb) s

Breakpoint 1, suspendAllThreads (self=0xb46ea0) at thread.c:928
928	            sched_yield();
(gdb)

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Robert Lougher wrote:
> On 21 June 2012 15:34, Darryl Miles<dar...@ne...>  wrote:
>> Robert Lougher wrote:
>>
>> When using 'strace' on the JamVM it was sleeping on FUTEX.
>>
>> I tried to kill -QUIT a few times and it seemed to then eat 100% CPU on a
>> core, I did not see any Thread Dump output in logs or console and after
>> allowing it a few minutes at 100% CPU I 'kill -9'.  Maybe it was already
>> eating CPU.
>>
>>
>> So what things might I do to investigate the matter further.
>
> I'd be interested in running the tests myself.  Are there any instructions?
>
> The fix allows the example that Xerxes posted to start up.  I've ran
> all the demos in that example, and they all seem to work OK.

Check project from GIT via 
https://qt.gitorious.org/qt-jambi/qtjambi-community

setup $JAVA_HOME and java and javac on $PATH
# Any JDK5+
# I am using the default OpenJDK as I'd like to have tests working
#  before using JamVM to build the project.

# Ant 1.8.x (there is patch around to change a few lines to use 1.7.x)
setup $ANT_HOME and ant on $PATH

# Configure QtJambi project to point at your Qt implementation
#  if you built it yourself or are using Windows or MacOSX you can use:
#  export $QTDIR=/my/dir/qt-4.7.4
#  add $QTDIR/bin to $PATH
#
#  if you are using the Linux system Qt (ensure you have all
#    *-devel packages installed)
#  edit build.properties to point to your system paths
#    /usr/lib64/qt4/ is a good place for much of what is needed
#    on Fedora/RHEL/CentOS

# Using junit 4.8.x
setup test.properties (pointing to a junit.jar)

# It should build with Qt 4.5.x through to 4.8.x
# If you are having problems you might want to run "ant init.build"
#  before trying 'all' target since it will save you time if your build
#  takes a while to complete; and look in the output for problems,
#  this is the first thing you'd be asked to assist resolving
#  any issues.
# export MAKEOPTS="-j2"  # work to speed up C/C++ parts
# Build takes less than 20 minutes on linux with 5 year old hardware
execute 'ant all tests.compile'

## Now you can switch environment to use JamVM

edit build_autotest.xml and XML comment out the references to "-Xrs" JVM 
argument (maybe you want to comment out other things like 
debug.level=255 and QTJAMBI_DEBUG_TRACE to reduce the amount of console 
output).

execute 'ant tests.run' to run the tests

## Be ready to kill the JamVM java process if it appears to be stuck
##  do this around 8 times and eventually the tests will finish and
##  a report get produced.

examine build/tests/TestResults*/index.html for the results.

# You'll want to run tests in isolation now to see what is going on.


Any problems getting the build environment working we're on IRC 
irc.freenode.net in #qtjambi



Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Robert L. <rob...@gm...>]

Hi,

On 21 June 2012 15:34, Darryl Miles <dar...@ne...> wrote:
> Robert Lougher wrote:
>>
>
> When using 'strace' on the JamVM it was sleeping on FUTEX.
>
> I tried to kill -QUIT a few times and it seemed to then eat 100% CPU on a
> core, I did not see any Thread Dump output in logs or console and after
> allowing it a few minutes at 100% CPU I 'kill -9'.  Maybe it was already
> eating CPU.
>
>
> So what things might I do to investigate the matter further.
>

I'd be interested in running the tests myself.  Are there any instructions?

The fix allows the example that Xerxes posted to start up.  I've ran
all the demos in that example, and they all seem to work OK.

Thanks,
Rob.

>
> Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Robert Lougher wrote:
> On 19 June 2012 18:22, Robert Lougher<rob...@gm...>  wrote:
>> I hope to check the fix in tonight.
>
> The fixes have now been pushed.  I've also regenerated the JNI stubs.

I have rebuilt JamVM re-run ./autogen.sh and make as per 
http://draenog.blogspot.se/2011/02/openjdkjamvm-git-repository.html


$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.1) (fedora-65.1.11.1.fc16 x86_64)
JamVM (build 1.6.0-devel, inline-threaded interpreter)



I have then run the JUnit Tests for QtJambi against and they mostly pass 
however I have about 8 error and 6 fails.  I needed to "kill -9" the 
JamVM around 8 times as it seemed to be making no progress after being 
allowed to run for 8 to 20 minutes for each test that hung.

Normal the entire suite  of around 500 tests on JDK5 takes under 10 
minutes, in total over an hour was given to allow JamVM to run and the 
process killed around the 10 minute point when a test did not look to be 
making progress.

(FWIW The QtJambi project has previously been built using Sun JDK5 and 
unit tests, so the only thing that changed is the libjvm.so in use for 
the test execution)



When using 'strace' on the JamVM it was sleeping on FUTEX.

I tried to kill -QUIT a few times and it seemed to then eat 100% CPU on 
a core, I did not see any Thread Dump output in logs or console and 
after allowing it a few minutes at 100% CPU I 'kill -9'.  Maybe it was 
already eating CPU.


So what things might I do to investigate the matter further.


Darryl

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Robert L. <rob...@gm...>]

Hi,

On 19 June 2012 18:22, Robert Lougher <rob...@gm...> wrote:
>
> I hope to check the fix in tonight.
>

The fixes have now been pushed.  I've also regenerated the JNI stubs.

Rob.

> Thanks for your help,
> Rob.
>
>>
>> HTH
>>
>> Darryl
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Jamvm-general mailing list
>> Jam...@li...
>> https://lists.sourceforge.net/lists/listinfo/jamvm-general

Re: [Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Robert L. <rob...@gm...>]

Hi Darryl,

On 19 June 2012 17:03, Darryl Miles <dar...@ne...> wrote:
> export QTJAMBI_DEBUG_TRACE=true
>
>
> Based on current qtjambi-community HEAD and current JamVM from git.
>
> Here is the JNI implementation of QApplication::desktop()
>
> ./build/generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp
>
> // QApplication::desktop()
> extern "C" Q_DECL_EXPORT jobject JNICALL QTJAMBI_FUNCTION_PREFIX(Java_com_trolltech_qt_gui_QApplication_desktop__)
> (JNIEnv *__jni_env,
>  jclass)
> {
>     QTJAMBI_DEBUG_TRACE("(native) entering: QApplication::desktop()");
>     Q_UNUSED(__jni_env)
>     QDesktopWidget*  __qt_return_value = QtJambiShell_QApplication::desktop();
>
>     jobject __java_return_value = qtjambi_from_qobject(__jni_env, (QObject *) __qt_return_value, "QDesktopWidget", "com/trolltech/qt/gui/");
>     QTJAMBI_EXCEPTION_CHECK(__jni_env);
>     QTJAMBI_DEBUG_TRACE("(native) ->  leaving: QApplication::desktop()");
>     return __java_return_value;
> }
>

Thanks for doing this.  It's great to see the actual generated code
and the tracing looks very useful.  I got lucky, and from a
disassembly of  QApplication::desktop() saw that it was calling
qtjambi_from_qobject() which I was able to find.

This creates a Java level object for a Qt object which it then links
all together via a link object (or something like that).  The
important thing is that it creates a JNI global reference to the
object which ends up getting returned by the native method (it also
uses weak JNI references).

In JamVM, JNI references are direct references and not handles.  To
implement GetObjectRefType() (a new JNI function in Java 1.6), I ended
up using the bottom 2 bits of the reference as tag bits.  This means
whenever a JNI reference is passed from a JNI method and then used
within the VM the bottom 2 bits must be masked off.

It appears that I missed out this masking off in 2 places (among
dozens).  This has been like it since Jan 2010, so I'm really
surprised it's taken so long to show up!

I hope to check the fix in tonight.

Thanks for your help,
Rob.

>
> HTH
>
> Darryl
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Jamvm-general mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamvm-general

[Jamvm-general] QtJambi / JamVM QApplication::desktop() crashing

[Darryl M. <dar...@ne...>]

Sorry this is not in the same thread I only just joined this list.




export QTJAMBI_DEBUG_TRACE=true


gdb --args java -cp qtjambi-4.7.4-debug.jar:build/platform-output-debug:qtjambi-examples-4.7.4.jar com.trolltech.launcher.Launcher
... SNIP ...
(native) ->  leaving: QSplashScreen::QSplashScreen(const QPixmap&  pixmap, QFlags<Qt::WindowType>  f); ( ../../generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QSplashScreen.cpp:2171 )
(native) entering: QApplication::desktop(); ( ../../generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp:1357 )
(native) ->  leaving: QApplication::desktop(); ( ../../generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp:1363 )

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f4d9c466700 (LWP 25350)]
0x00007f4d9c72fbab in executeJava () at interp.c:2182
2182        DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {
Missing separate debuginfos, use: debuginfo-install glib2-2.30.3-1.fc16.x86_64 libuuid-2.20.1-2.3.fc16.x86_64
(gdb) bt
#0  0x00007f4d9c72fbab in executeJava () at interp.c:2182
#1  0x00007f4d9c71c59b in executeMethodVaList (ob=0x0, class=0x7f4d540c0610, mb=0x7f4d943c3c70, jargs=0x7f4d9c465d78) at execute.c:129
#2  0x00007f4d9c71d808 in Jam_CallStaticVoidMethod (env=<optimized out>, clazz=<optimized out>, methodID=<optimized out>) at jni.c:1221
#3  0x0000000000403c27 in JavaMain ()
#4  0x000000326b607d90 in start_thread (arg=0x7f4d9c466700) at pthread_create.c:309
#5  0x000000326aaf0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) frame 0
#0  0x00007f4d9c72fbab in executeJava () at interp.c:2182
2182        DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {


Based on current qtjambi-community HEAD and current JamVM from git.



Here is the JNI implementation of QApplication::desktop()


./build/generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp

// QApplication::desktop()
extern "C" Q_DECL_EXPORT jobject JNICALL QTJAMBI_FUNCTION_PREFIX(Java_com_trolltech_qt_gui_QApplication_desktop__)
(JNIEnv *__jni_env,
  jclass)
{
     QTJAMBI_DEBUG_TRACE("(native) entering: QApplication::desktop()");
     Q_UNUSED(__jni_env)
     QDesktopWidget*  __qt_return_value = QtJambiShell_QApplication::desktop();

     jobject __java_return_value = qtjambi_from_qobject(__jni_env, (QObject *) __qt_return_value, "QDesktopWidget", "com/trolltech/qt/gui/");
     QTJAMBI_EXCEPTION_CHECK(__jni_env);
     QTJAMBI_DEBUG_TRACE("(native) ->  leaving: QApplication::desktop()");
     return __java_return_value;
}

./build/generator/out/java/com/trolltech/qt/gui/QApplication.java:
      public native static com.trolltech.qt.gui.QDesktopWidget desktop();




Now I set a "break Java_com_trolltech_qt_gui_QApplication_desktop__" and next through the JNI implementation method shown above and then back into the JamVM where it quickly has the crash.



Breakpoint 1, Java_com_trolltech_qt_gui_QApplication_desktop__ (__jni_env=0x7f40661c9960) at ../../generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp:1357
1357        QTJAMBI_DEBUG_TRACE("(native) entering: QApplication::desktop()");
Missing separate debuginfos, use: debuginfo-install glib2-2.30.3-1.fc16.x86_64 libuuid-2.20.1-2.3.fc16.x86_64
(gdb) n
(native) entering: QApplication::desktop(); ( ../../generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp:1357 )
1359        QDesktopWidget*  __qt_return_value = QtJambiShell_QApplication::desktop();
(gdb)
1361        jobject __java_return_value = qtjambi_from_qobject(__jni_env, (QObject *) __qt_return_value, "QDesktopWidget", "com/trolltech/qt/gui/");
(gdb) p __qt_return_value
$1 = (QDesktopWidget *) 0x7f406092e890
(gdb) p *__qt_return_value
$2 = {<QWidget>  = {<QObject>  = {_vptr.QObject = 0x7f4007009730, static staticMetaObject = {d = {superdata = 0x0, stringdata = 0x7f4007d57e20 "QObject", data = 0x7f4007d57d60, extradata =
     0x7f4007ff0920}}, d_ptr = {d = 0x7f4060947790}, static staticQtMetaObject = {d = {superdata = 0x0, stringdata = 0x7f4007d64f80 "Qt", data = 0x7f4007d62ce0, extradata = 0x0}}},
     <QPaintDevice>  = {_vptr.QPaintDevice = 0x7f40070098f0, painters = 0}, static staticMetaObject = {d = {superdata = 0x7f4007ff0900, stringdata = 0x7f4006b11e60 "QWidget", data =
     0x7f4006b119a0, extradata = 0x0}}, data = 0x7f40609478e0}, static staticMetaObject = {d = {superdata = 0x7f4006fe8720, stringdata = 0x7f4006b9b080 "QDesktopWidget", data = 0x7f4006b9afc0,
       extradata = 0x0}}}
(gdb) n
1362        QTJAMBI_EXCEPTION_CHECK(__jni_env);
(gdb)
1363        QTJAMBI_DEBUG_TRACE("(native) ->  leaving: QApplication::desktop()");
(gdb)
(native) ->  leaving: QApplication::desktop(); ( ../../generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp:1363 )
1364        return __java_return_value;
(gdb)
1365    }
(gdb)
static__I (class=0x7f402026e088, mb=0x7f406078e850, ostack=0x7f40651b92f8) at jni-stubs.c:22
22          return ostack + 1;
(gdb) p ostack
$3 = (uintptr_t *) 0x7f40651b92f8
(gdb) n
18          *ostack = (*(uintptr_t (*)(void*, void*))mb->code) (
(gdb)
23      }
(gdb)
executeJava () at interp.c:2233
2233            if(sync_ob)
(gdb)
2231            ostack = (*new_mb->native_invoker)(new_mb->class, new_mb, arg1);
(gdb)
2233            if(sync_ob)
(gdb)
2238            if(exceptionOccurred0(ee))
(gdb)
2240            DISPATCH(0, *pc == OPC_INVOKEINTERFACE_QUICK ? 5 : 3);
(gdb)
2236            ee->last_frame = frame;
(gdb)
2238            if(exceptionOccurred0(ee))
(gdb)
2251        DISPATCH_FIRST
(gdb)
77          INTERPRETER_PROLOGUE
(gdb)
1426        DEF_OPC_RW(OPC_INVOKEVIRTUAL, ({
(gdb)
77          INTERPRETER_PROLOGUE
(gdb)
2182        DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x00007f4065faebab in executeJava () at interp.c:2182
2182        DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {


gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00007f40050a55f3 in Java_com_trolltech_qt_gui_QApplication_desktop__(JNIEnv*, jclass)
                                                    at ../../generator/out/cpp/com_trolltech_qt_gui/qtjambishell_QApplication.cpp:1357
         breakpoint already hit 1 time



HTH

Darryl

Re: [Jamvm-general] QT-Jambi sigsegv at startup issue.

[Robert L. <rob...@gm...>]

On 16 June 2012 13:23, Robert Lougher <rob...@gm...> wrote:
> On 16 June 2012 13:19, Robert Lougher <rob...@gm...> wrote:
>> Hi,
>>
>> On 15 June 2012 12:27, Xerxes Rånby <xe...@za...> wrote:
>>> Updated testcase to use the last stable qt-jambi 4.6 community supported version, the 4.7 beta version consumed a lot of memory and can freeze the desktop on some Linux setups.
>>>
>>> 2012-06-15 12:10, Xerxes Rånby skrev:
>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x003543d7 in executeJava () at interp.c:2182
>>>> 2182      DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {
>>>> (gdb) bt
>>>> #0  0x003543d7 in executeJava () at interp.c:2182
>>>> #1  0x0033ba70 in executeMethodVaList (ob=0x0, class=0x993d3c50,
>>>>     mb=0x94334254, jargs=0xb7fdc300 "") at execute.c:129
>>>> #2  0x0033d3e6 in Jam_CallStaticVoidMethod (env=0x377900, clazz=0x993d3c50,
>>>>     methodID=0x94334254) at jni.c:1221
>>>> #3  0x0804baa9 in JavaMain ()
>>>> #4  0x00138d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
>>>> #5  0x00242ace in clone () from /lib/i386-linux-gnu/libc.so.6
>>>>
>>
>> The call to the JNI function QApplication.display() appears to be
>> returning junk.  I can't seem to find the source code for QApplication
>> (let alone the native code) anywhere.  I've cloned the community git
>> repository but it's missing.  Tracking this down without source code
>> will obviously take longer.
>>
>
> That should be QApplication.desktop() not display().
>

OK, QApplication is auto-generated and is just a bunch of native methods.

> Rob.
>
>> Rob.
>>
>>>> Cheers
>>>> Xerxes
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Jamvm-general mailing list
>>> Jam...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jamvm-general

Re: [Jamvm-general] QT-Jambi sigsegv at startup issue.

[Robert L. <rob...@gm...>]

On 16 June 2012 13:19, Robert Lougher <rob...@gm...> wrote:
> Hi,
>
> On 15 June 2012 12:27, Xerxes Rånby <xe...@za...> wrote:
>> Updated testcase to use the last stable qt-jambi 4.6 community supported version, the 4.7 beta version consumed a lot of memory and can freeze the desktop on some Linux setups.
>>
>> 2012-06-15 12:10, Xerxes Rånby skrev:
>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x003543d7 in executeJava () at interp.c:2182
>>> 2182      DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {
>>> (gdb) bt
>>> #0  0x003543d7 in executeJava () at interp.c:2182
>>> #1  0x0033ba70 in executeMethodVaList (ob=0x0, class=0x993d3c50,
>>>     mb=0x94334254, jargs=0xb7fdc300 "") at execute.c:129
>>> #2  0x0033d3e6 in Jam_CallStaticVoidMethod (env=0x377900, clazz=0x993d3c50,
>>>     methodID=0x94334254) at jni.c:1221
>>> #3  0x0804baa9 in JavaMain ()
>>> #4  0x00138d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
>>> #5  0x00242ace in clone () from /lib/i386-linux-gnu/libc.so.6
>>>
>
> The call to the JNI function QApplication.display() appears to be
> returning junk.  I can't seem to find the source code for QApplication
> (let alone the native code) anywhere.  I've cloned the community git
> repository but it's missing.  Tracking this down without source code
> will obviously take longer.
>

That should be QApplication.desktop() not display().

Rob.

> Rob.
>
>>> Cheers
>>> Xerxes
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Jamvm-general mailing list
>> Jam...@li...
>> https://lists.sourceforge.net/lists/listinfo/jamvm-general

Re: [Jamvm-general] QT-Jambi sigsegv at startup issue.

[Robert L. <rob...@gm...>]

Hi,

On 15 June 2012 12:27, Xerxes Rånby <xe...@za...> wrote:
> Updated testcase to use the last stable qt-jambi 4.6 community supported version, the 4.7 beta version consumed a lot of memory and can freeze the desktop on some Linux setups.
>
> 2012-06-15 12:10, Xerxes Rånby skrev:

>> Program received signal SIGSEGV, Segmentation fault.
>> 0x003543d7 in executeJava () at interp.c:2182
>> 2182      DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {
>> (gdb) bt
>> #0  0x003543d7 in executeJava () at interp.c:2182
>> #1  0x0033ba70 in executeMethodVaList (ob=0x0, class=0x993d3c50,
>>     mb=0x94334254, jargs=0xb7fdc300 "") at execute.c:129
>> #2  0x0033d3e6 in Jam_CallStaticVoidMethod (env=0x377900, clazz=0x993d3c50,
>>     methodID=0x94334254) at jni.c:1221
>> #3  0x0804baa9 in JavaMain ()
>> #4  0x00138d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
>> #5  0x00242ace in clone () from /lib/i386-linux-gnu/libc.so.6
>>

The call to the JNI function QApplication.display() appears to be
returning junk.  I can't seem to find the source code for QApplication
(let alone the native code) anywhere.  I've cloned the community git
repository but it's missing.  Tracking this down without source code
will obviously take longer.

Rob.

>> Cheers
>> Xerxes
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Jamvm-general mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamvm-general

Re: [Jamvm-general] QT-Jambi sigsegv at startup issue.

[Robert L. <rob...@gm...>]

Hi Xerxes,

On 15 June 2012 12:27, Xerxes Rånby <xe...@za...> wrote:
> Updated testcase to use the last stable qt-jambi 4.6 community supported version, the 4.7 beta version consumed a lot of memory and can freeze the desktop on some Linux setups.
>
> 2012-06-15 12:10, Xerxes Rånby skrev:
>> Hi
>> I am testing JamVM git head + OpenJDK 6 1.11.1 against the qt-jambi framework on a 32bit x86 machine:
>>
>> http://qt-jambi.org/ - Qt Jambi 4.7 beta this is the current actively maintained community supported version.
> http://qt-jambi.org/downloads - Qt Jambi 4.6 stable download page.
>> http://qt-project.org/wiki/Qt_Jambi - Qt Jambi 4.5.2_01. This is last version by the Qt team.
>
> Testcase:
> wget http://downloads.sourceforge.net/project/qtjambi/4.6.3/qtjambi-linux32-community-4.6.3.tar.gz
> tar zxvf qtjambi-linux32-community-4.6.3.tar.gz
> cd qtjambi-linux32-community-4.6.3
> ./qtjambi.sh
>
>> the ./qtjambi.sh launches:
> /usr/bin/java -cp ./qtjambi-util-4.6.3.jar:./qtjambi-linux32-gcc-4.6.3.jar:./qtjambi-examples-4.6.3.jar:./qtjambi-designer-4.6.3.jar:./qtjambi-4.6.3.jar: com.trolltech.launcher.Launcher
>
>>
>> I get an immediate crash during qt-jambi startup while using jamvm in contrast both cacao and hotspot work to launch these qt-jambi examples.
>> I hit the same issue for both the 4.7 and 4.5.2 version.
>>

If it crashes immediately on startup it should be relatively easy to
find.  I'll have a look over the weekend.

Thanks,
Rob.

>>
>> Cheers
>> Xerxes
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Jamvm-general mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamvm-general