[cp-patches] Re: Assertion failure
Hi, On Tue, 2006-01-10 at 19:26 +0100, Mark Wielaard wrote: Agreed. I am still hoping someone has a good analysis of the issue, or wants to upgrade our mprec to the newlib version. If not we should indeed disable the assert again before 0.20 is released. Which is what I did. For now we just disabled the assert to get us the behavior we had before. After 0.20 we should solve this correctly. I have updated the bug report to mention the things discussed in the two threads about this. 2006-01-12 Mark Wielaard [EMAIL PROTECTED] * native/fdlibm/mprec.c (Balloc): Disable assert to workaround PR classpath/23863. This solves all mauve regressions we were seeing. It would be appreciated if others could also rerun their tests with this applied. Committed, Mark diff -u -r1.6 mprec.c --- native/fdlibm/mprec.c 6 Jan 2006 01:27:20 - 1.6 +++ native/fdlibm/mprec.c 12 Jan 2006 09:20:55 - @@ -97,7 +97,9 @@ int i = 0; int j = 1; - assert ((1 k) MAX_BIGNUM_WDS); + /* FIXME - assert disabled because of PR classpath/23863 + * assert ((1 k) MAX_BIGNUM_WDS); + */ while ((ptr-_allocation_map j) i MAX_BIGNUMS) i++, j = 1; signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: Assertion failure
Hi, On Tue, 2006-01-10 at 01:38 +0100, Christian Thalinger wrote: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Christian Thalinger writes: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Yes, but what is the value of k when this assertion fires? Andrew. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Tue, 2006-01-10 at 10:41 +0100, Mark Wielaard wrote: Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Hi, On Tue, 2006-01-10 at 10:17 +, Andrew Haley wrote: Christian Thalinger writes: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Yes, but what is the value of k when this assertion fires? You can trigger it with the following (extracted from Mauve): new java.math.BigDecimal(1e200).floatValue(); Which gives: #4 0xad75ab88 in _Jv_Balloc (ptr=0xbfa7b7d4, k=5) at mprec.c:100 100 assert ((1 k) MAX_BIGNUM_WDS); Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard writes: On Tue, 2006-01-10 at 10:41 +0100, Mark Wielaard wrote: Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. BTW, does anybody know why we are not using the system strtod() when available? Java has some very specific requirements for floating-point to decimal conversion, and this library satisfies those requirements. strtod() doesn't, or may not. Andrew. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Tue, 2006-01-10 at 11:49 +0100, Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? OK found that out myself. Apparently some strtod implementations are indeed not thread-safe by default (but most seem to be). The other problem is that strtod depends on the locale and changing the locale isn't thread-safe... sigh. So we do need our own implementation, or do something like glib g_ascii_strtod() and convert the string representation first to the current locale form (). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from Balloc in mprec.c. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard wrote: On Tue, 2006-01-10 at 11:49 +0100, Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? OK found that out myself. Apparently some strtod implementations are indeed not thread-safe by default (but most seem to be). The other problem is that strtod depends on the locale and changing the locale isn't thread-safe... sigh. So we do need our own implementation, or do something like glib g_ascii_strtod() and convert the string representation first to the current locale form (). In addition, many strotod implementations I encountered are subtly different when it comes to having the results that the Java specs demand for very small values. I guess that has a lot to do with floating point rounding modes being largely implementation dependant in C89 [1], so when porting to a C89-ish strtod one can only hope that the libc in question has been compiled with the right options/switches/assembly. :/ cheers, dalibor topic [1] that's one of the reasons why I prefer C99 over C89, personally. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Archie Cobbs wrote: Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from Balloc in mprec.c. Sorry for the noise, that email got delayed several hours for some reason. As we now know strtod() has different behavior than desired... In any case, we probably need to fix this before 0.20, or at least disable the assertion (i.e., revert to the previous status quo). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Hi Archie, On Tue, 2006-01-10 at 11:59 -0600, Archie Cobbs wrote: In any case, we probably need to fix this before 0.20, or at least disable the assertion (i.e., revert to the previous status quo). Agreed. I am still hoping someone has a good analysis of the issue, or wants to upgrade our mprec to the newlib version. If not we should indeed disable the assert again before 0.20 is released. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Assertion failure
FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug classpath/23859] New: Assertion failure when calling JTabbedPane.addTab(null, ...)
Thanks to gcj's ability to compile native code that can be debugged with
gdb, I finally could narrow down and report this bug that I first
noticed with libgcj4 or libgcj5. The program runs fine under Sun's JVM,
but libgcj aborts because of an assertion failure.
I keep getting an assertion failure and SIGABRT when my program calls
JTabbedPane.addTab() with null first argument. If I replace the first
argument with a string (even an empty one) or if I run the code under
Sun's JVM, there is no assertion failure. Here is a minimal test case:
cat crash.java EOF
import javax.swing.JTabbedPane;
import javax.swing.JTable;
class crash
{
public static final void main (String args[]) {
JTabbedPane t = new JTabbedPane ();
JTable jt = new JTable ();
t.addTab (null, null, jt);
}
}
EOF
gcj-4.0 --main=crash crash.java
./a.out
** ERROR **: file
../../../src/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkFontPeer.c: line 290
(Java_gnu_java_awt_peer_gtk_GdkFontPeer_getTextMetrics): assertion failed: (cstr
!= NULL)
aborting...
Replace the first argument of t.addTab() with , and the assertion
won't fail. Note that the program works under Sun's JVM.
Marko
--
Summary: Assertion failure when calling JTabbedPane.addTab(null,
...)
Product: classpath
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: classpath
AssignedTo: roman at kennke dot org
ReportedBy: konqueror at gmx dot de
CC: bug-classpath at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23859
___
Bug-classpath mailing list
Bug-classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/20782] jawt assertion failure
--- Additional Comments From fitzsim at redhat dot com 2005-08-31 21:57 --- Fixed in GNU Classpath. Closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20782 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: JNI assertion failure
I checked in the aforementioned assertion patch. 2005-07-25 Archie Cobbs [EMAIL PROTECTED] * native/jni/classpath/native_state.c: add assertion for object type -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Dalibor Topic wrote:
Doesn't GetObjectClass change the state of env? If that's the case, it
maybe shouldn't be an assert.
Not sure what you mean.. but there is a bug: we need to delete the
local native reference obtained by calling GetObjectClass.
Attached is a better patch.
Thanks,
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: native/jni/classpath/native_state.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/native_state.c,v
retrieving revision 1.11
diff -u -r1.11 native_state.c
--- native/jni/classpath/native_state.c 14 Jul 2005 22:07:02 - 1.11
+++ native/jni/classpath/native_state.c 24 Jul 2005 22:38:39 -
@@ -36,6 +36,7 @@
exception statement from your version. */
#include stdlib.h
+#include assert.h
#include jni.h
#include native_state.h
@@ -165,6 +166,18 @@
*head = new_node;
}
+#ifndef NDEBUG
+static void
+cp_gtk_check_compat (JNIEnv * env, jobject obj, struct state_table *table)
+{
+ jclass objclazz;
+
+ objclazz = (*env)-GetObjectClass(env, obj);
+ assert ((*env)-IsAssignableFrom(env, objclazz, table-clazz));
+ (*env)-DeleteLocalRef(env, objclazz);
+}
+#endif
+
void
cp_gtk_set_state_oid (JNIEnv * env, jobject lock, struct state_table *table,
jint obj_id, void *state)
@@ -214,6 +227,11 @@
cp_gtk_set_state (JNIEnv * env, jobject obj, struct state_table *table, void
*state)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -227,6 +245,11 @@
cp_gtk_get_state (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -239,6 +262,11 @@
cp_gtk_remove_state_slot (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Archie Cobbs wrote:
With Classpath 0.16, trying to run a very simple Swing demo under JCVM,
I get a JNI assertion failure in a call to GetIntField(), because the
object
type and the fieldID are not compatible:
gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of
gnu/java/awt/peer/gtk/GtkGenericPeer
Here is the relevant stack trace snippet:
#7 0x29f862d7 in
Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2
(env=0x107ed6a0, obj=0x29795698, peer=0x2979569c)
at gnu_java_awt_peer_gtk_GdkGraphics.c:154
Hmm, no response.. can anyone else confirm this problem??
It looks like this code is completely broken, because
it's trying to save a pointer in a field that doesn't
exist. Line 154 of gnu_java_awt_peer_gtk_GdkGraphics.c says:
NSA_SET_PTR (env, obj, g)
but obj is a gnu/java/awt/peer/gtk/GdkGraphics object, not
a gnu/java/awt/peer/gtk/GtkGenericPeer object, the class that
contains the native_state field.
Since nobody seems to be listening, I'm going to check in the
attached patch. This will cause all programs that use the GTK
peer to crash with an assertion failure. Sorry! The code
is broken but I don't know how to fix it. At least now we get
an assertion failure instead of random memory corruption.
You have been warned :-)
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: native/jni/classpath/native_state.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/native_state.c,v
retrieving revision 1.11
diff -u -r1.11 native_state.c
--- native/jni/classpath/native_state.c 14 Jul 2005 22:07:02 - 1.11
+++ native/jni/classpath/native_state.c 23 Jul 2005 19:30:28 -
@@ -36,6 +36,7 @@
exception statement from your version. */
#include stdlib.h
+#include assert.h
#include jni.h
#include native_state.h
@@ -214,6 +215,10 @@
cp_gtk_set_state (JNIEnv * env, jobject obj, struct state_table *table, void
*state)
{
jint obj_id;
+
+ assert ((*env)-IsAssignableFrom(env,
+(*env)-GetObjectClass(env, obj), table-clazz));
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -227,6 +232,10 @@
cp_gtk_get_state (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+ assert ((*env)-IsAssignableFrom(env,
+(*env)-GetObjectClass(env, obj), table-clazz));
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -239,6 +248,10 @@
cp_gtk_remove_state_slot (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+ assert ((*env)-IsAssignableFrom(env,
+(*env)-GetObjectClass(env, obj), table-clazz));
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Archie Cobbs wrote: Archie Cobbs wrote: With Classpath 0.16, trying to run a very simple Swing demo under JCVM, I get a JNI assertion failure in a call to GetIntField(), because the object type and the fieldID are not compatible: gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of gnu/java/awt/peer/gtk/GtkGenericPeer Here is the relevant stack trace snippet: #7 0x29f862d7 in Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2 (env=0x107ed6a0, obj=0x29795698, peer=0x2979569c) at gnu_java_awt_peer_gtk_GdkGraphics.c:154 Hmm, no response.. can anyone else confirm this problem?? It looks like this code is completely broken, because it's trying to save a pointer in a field that doesn't exist. Line 154 of gnu_java_awt_peer_gtk_GdkGraphics.c says: NSA_SET_PTR (env, obj, g) but obj is a gnu/java/awt/peer/gtk/GdkGraphics object, not a gnu/java/awt/peer/gtk/GtkGenericPeer object, the class that contains the native_state field. Since nobody seems to be listening, I'm going to check in the attached patch. This will cause all programs that use the GTK peer to crash with an assertion failure. Sorry! The code is broken but I don't know how to fix it. At least now we get an assertion failure instead of random memory corruption. You have been warned :-) Heh. ;) + assert ((*env)-IsAssignableFrom(env, +(*env)-GetObjectClass(env, obj), table-clazz)); + obj_id = (*env)-GetIntField (env, obj, table-hash); Doesn't GetObjectClass change the state of env? If that's the case, it maybe shouldn't be an assert. cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Archie Cobbs wrote: With Classpath 0.16, trying to run a very simple Swing demo under JCVM, I get a JNI assertion failure in a call to GetIntField(), because the object type and the fieldID are not compatible: gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of gnu/java/awt/peer/gtk/GtkGenericPeer Here is the relevant stack trace snippet: #7 0x29f862d7 in Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2 (env=0x107ed6a0, obj=0x29795698, peer=0x2979569c) at gnu_java_awt_peer_gtk_GdkGraphics.c:154 Hmm, no response.. can anyone else confirm this problem?? It looks like this code is completely broken, because it's trying to save a pointer in a field that doesn't exist. Line 154 of gnu_java_awt_peer_gtk_GdkGraphics.c says: NSA_SET_PTR (env, obj, g) but obj is a gnu/java/awt/peer/gtk/GdkGraphics object, not a gnu/java/awt/peer/gtk/GtkGenericPeer object, the class that contains the native_state field. I'm not familiar with this code so I could be completely misunderstanding something. But it seems obviously wrong, and on VM's that don't check proper JNI usage will result in random memory corruption. I'd appreciate a quick confirmation from another set of eyes... Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
JNI assertion failure
With Classpath 0.16, trying to run a very simple Swing demo under JCVM, I get a JNI assertion failure in a call to GetIntField(), because the object type and the fieldID are not compatible: gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of gnu/java/awt/peer/gtk/GtkGenericPeer Here is the relevant stack trace snippet: #4 0x282d6c1b in abort () from /lib/libc.so.5 #5 0x280ae91d in GetIntField (jenv=0x107ed6a0, obj=0x29795698, field=0x107527c8) at jni_native.c:82 #6 0x29f99d72 in set_state (env=0x107ed6a0, obj=0x29795698, table=0x10471440, state=0x109ea4c0) at native_state.c:217 #7 0x29f862d7 in Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2 (env=0x107ed6a0, obj=0x29795698, peer=0x2979569c) at gnu_java_awt_peer_gtk_GdkGraphics.c:154 #8 0x280d4289 in _jc_dynamic_invoke (func=0x29f86214, jcni=0, nparams=3, ptypes=0x2979562c \n\n\n\t, nwords=3, words=0x29795620, retval=0x107ed628) at arch/i386/arch_functions.c:336 #9 0x280aa802 in _jc_invoke_jni_a (env=0x107ed600, method=0x107f9d60, func=0x29f86214, obj=0x85e0308, params=0x29795754) at invoke.c:692 Could an AWT person take a look at the above trace and error? Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
