sablevm-bugs Mailing List for SableVM (Page 7)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-bugs — SableVM bugs mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(16) |
Sep
(10) |
Oct
|
Nov
(2) |
Dec
(7) |
| 2003 |
Jan
(14) |
Feb
(11) |
Mar
(59) |
Apr
(3) |
May
(1) |
Jun
(7) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(26) |
Apr
|
May
|
Jun
(1) |
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <no...@so...> - 2002-12-10 03:21:59
|
Bugs item #651250, was opened at 2002-12-09 19:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=651250&group_id=5523 Category: Execution Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in LineNumberReader.java Initial Comment: I was trying to run an app and got an exception that looked like this: java.io.IOException: Pushback buffer is full at java.io.PushbackReader.unread(PushbackReader.java:319) at java.io.LineNumberReader.read(LineNumberReader.java:246) ... This appears to be a bug in LineNumberReader.java, which the patch below seems to fix. --- work/sablevm-class-library-1.0.5/src/java/io/LineNumberReader.java.orig Mon Dec 9 19:12:35 2002 +++ work/sablevm-class-library-1.0.5/src/java/io/LineNumberReader.java Mon Dec 9 19:12:02 2002 @@ -115,7 +115,7 @@ public LineNumberReader(Reader in, int size) { - super(new PushbackReader(in), size); + super(in, size); } /*************************************************************************/ @@ -243,7 +243,7 @@ int extra_char_read = super.read(); if ((extra_char_read != '\n') && (extra_char_read != -1)) - ((PushbackReader)in).unread(extra_char_read); + pos--; char_read = '\n'; ++line_number; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=651250&group_id=5523 |
|
From: <no...@so...> - 2002-11-20 13:43:44
|
Bugs item #640976, was opened at 2002-11-19 18:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=640976&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Archie Cobbs (archiecobbs) >Assigned to: Etienne M. Gagnon (egagnon) Summary: Better error from Runtime.nativeLoad() Initial Comment: Here's a patch to fix a problem with Runtime.nativeLoad(). The problem is that if the dlopen() operation fails, the error message is lost. This caused me a lot of head scratching the other day trying to figure out why something wasn't working. With this patch the underlying error message (from lt_dlerror()) will appear in the Exception message string. ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2002-11-20 08:43 Message: Logged In: YES user_id=15365 Archie, The patch has been applied into the CVS repository. Thanks a lot for the patch! Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=640976&group_id=5523 |
|
From: <no...@so...> - 2002-11-19 23:23:00
|
Bugs item #640976, was opened at 2002-11-19 15:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=640976&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: Better error from Runtime.nativeLoad() Initial Comment: Here's a patch to fix a problem with Runtime.nativeLoad(). The problem is that if the dlopen() operation fails, the error message is lost. This caused me a lot of head scratching the other day trying to figure out why something wasn't working. With this patch the underlying error message (from lt_dlerror()) will appear in the Exception message string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=640976&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 17:40:02
|
Bugs item #607368, was opened at 2002-09-10 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 Category: Execution Problem Group: SableVM Status: Closed Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Etienne M. Gagnon (egagnon) Summary: bug in >>> operator? Initial Comment: I'm using the 1.0.3 version of sablevm, and it's associated classpath. The >>>= and >>> operators appear to be broken strangely. Demo class and output: =================================================== import java.lang.*; import java.awt.color.*; import java.awt.image.*; public class ShiftBug { public static void main (String argv[]) { long a = 0xff00; long b, c; b = a >>> 4; c = 0xff00 >>> 4; System.out.print (Long.toString(b,16) + " " + Long.toString(c,16) + "\n"); } } =================================================== Output: [esnyder@basalt esnyder]$ jikes -classpath /usr/local/lib/sablevm/classes-1.0.3 ShiftBug.java [esnyder@basalt esnyder]$ sablevm -Y ShiftBug ff000 ff0 thanks, -emile ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2002-09-10 13:40 Message: Logged In: YES user_id=15365 Fixed in CVS. Thanks! - Etienne ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 12:56 Message: Logged In: NO I believe it's just a typo in sablevm-1.0.3/src/libsablevm/instructions.m4.c If I change line 1477 (in the LUSR block) from *((jlong *) &stack[stack_size - 2]) = ((_svmt_u64) value1) << (value2 & 0x3f); <---- line 1477 to *((jlong *) &stack[stack_size - 2]) = ((_svmt_u64) value1) >> (value2 & 0x3f); <---- line 1477 Then the test program works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 17:39:12
|
Bugs item #602543, was opened at 2002-08-30 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 Category: Compilation Problem >Group: SablePath Status: Open Resolution: None Priority: 3 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: #include <malloc.h> is a Linux-ism Initial Comment: Please wrap instances of #include <malloc.h> within #ifdef HAVE_MALLOC_H . There are two instances in the sablevm-native-library tarball. <malloc.h> is a Linux-specific thing. All the world does not use Linux, sorry :-) ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2002-08-31 20:37 Message: Logged In: YES user_id=15365 This should be fixed in upstream GNU Classpath. I will do so. Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 17:38:53
|
Bugs item #607368, was opened at 2002-09-10 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Etienne M. Gagnon (egagnon) Summary: bug in >>> operator? Initial Comment: I'm using the 1.0.3 version of sablevm, and it's associated classpath. The >>>= and >>> operators appear to be broken strangely. Demo class and output: =================================================== import java.lang.*; import java.awt.color.*; import java.awt.image.*; public class ShiftBug { public static void main (String argv[]) { long a = 0xff00; long b, c; b = a >>> 4; c = 0xff00 >>> 4; System.out.print (Long.toString(b,16) + " " + Long.toString(c,16) + "\n"); } } =================================================== Output: [esnyder@basalt esnyder]$ jikes -classpath /usr/local/lib/sablevm/classes-1.0.3 ShiftBug.java [esnyder@basalt esnyder]$ sablevm -Y ShiftBug ff000 ff0 thanks, -emile ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 12:56 Message: Logged In: NO I believe it's just a typo in sablevm-1.0.3/src/libsablevm/instructions.m4.c If I change line 1477 (in the LUSR block) from *((jlong *) &stack[stack_size - 2]) = ((_svmt_u64) value1) << (value2 & 0x3f); <---- line 1477 to *((jlong *) &stack[stack_size - 2]) = ((_svmt_u64) value1) >> (value2 & 0x3f); <---- line 1477 Then the test program works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 16:56:19
|
Bugs item #607368, was opened at 2002-09-10 08:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Etienne M. Gagnon (egagnon) Summary: bug in >>> operator? Initial Comment: I'm using the 1.0.3 version of sablevm, and it's associated classpath. The >>>= and >>> operators appear to be broken strangely. Demo class and output: =================================================== import java.lang.*; import java.awt.color.*; import java.awt.image.*; public class ShiftBug { public static void main (String argv[]) { long a = 0xff00; long b, c; b = a >>> 4; c = 0xff00 >>> 4; System.out.print (Long.toString(b,16) + " " + Long.toString(c,16) + "\n"); } } =================================================== Output: [esnyder@basalt esnyder]$ jikes -classpath /usr/local/lib/sablevm/classes-1.0.3 ShiftBug.java [esnyder@basalt esnyder]$ sablevm -Y ShiftBug ff000 ff0 thanks, -emile ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 09:56 Message: Logged In: NO I believe it's just a typo in sablevm-1.0.3/src/libsablevm/instructions.m4.c If I change line 1477 (in the LUSR block) from *((jlong *) &stack[stack_size - 2]) = ((_svmt_u64) value1) << (value2 & 0x3f); <---- line 1477 to *((jlong *) &stack[stack_size - 2]) = ((_svmt_u64) value1) >> (value2 & 0x3f); <---- line 1477 Then the test program works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 15:50:18
|
Bugs item #607368, was opened at 2002-09-10 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None >Priority: 7 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Etienne M. Gagnon (egagnon) Summary: bug in >>> operator? Initial Comment: I'm using the 1.0.3 version of sablevm, and it's associated classpath. The >>>= and >>> operators appear to be broken strangely. Demo class and output: =================================================== import java.lang.*; import java.awt.color.*; import java.awt.image.*; public class ShiftBug { public static void main (String argv[]) { long a = 0xff00; long b, c; b = a >>> 4; c = 0xff00 >>> 4; System.out.print (Long.toString(b,16) + " " + Long.toString(c,16) + "\n"); } } =================================================== Output: [esnyder@basalt esnyder]$ jikes -classpath /usr/local/lib/sablevm/classes-1.0.3 ShiftBug.java [esnyder@basalt esnyder]$ sablevm -Y ShiftBug ff000 ff0 thanks, -emile ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 15:49:54
|
Bugs item #597368, was opened at 2002-08-19 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None >Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Etienne M. Gagnon (egagnon) Summary: Need to workaround the x86 division bug Initial Comment: /* test that we don't get tripped up by x86 problem */ public class divtest { public static int divfunc(int x, int y) { return x/y; } public static void main(String args[]) { int i = 0x80000000; int j = -1; int k = divfunc(i,j); // x86 causes trap for no good reason System.out.println("Result is "+Integer.toHexString(k)); } } This program should output "Result is 80000000" but instead we get (when running on i386): java.lang.ArithmeticException at divtest.divfunc(divtest.java:6) at divtest.main(divtest.java:14) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) Kaffe ran into this same problem. I don't know the details but it has something to do with an x86 integer division bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 15:49:35
|
Bugs item #602543, was opened at 2002-08-30 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 Category: Compilation Problem Group: SableVM Status: Open Resolution: None >Priority: 3 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: #include <malloc.h> is a Linux-ism Initial Comment: Please wrap instances of #include <malloc.h> within #ifdef HAVE_MALLOC_H . There are two instances in the sablevm-native-library tarball. <malloc.h> is a Linux-specific thing. All the world does not use Linux, sorry :-) ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2002-08-31 20:37 Message: Logged In: YES user_id=15365 This should be fixed in upstream GNU Classpath. I will do so. Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 |
|
From: <no...@so...> - 2002-09-10 15:48:20
|
Bugs item #607368, was opened at 2002-09-10 08:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bug in >>> operator? Initial Comment: I'm using the 1.0.3 version of sablevm, and it's associated classpath. The >>>= and >>> operators appear to be broken strangely. Demo class and output: =================================================== import java.lang.*; import java.awt.color.*; import java.awt.image.*; public class ShiftBug { public static void main (String argv[]) { long a = 0xff00; long b, c; b = a >>> 4; c = 0xff00 >>> 4; System.out.print (Long.toString(b,16) + " " + Long.toString(c,16) + "\n"); } } =================================================== Output: [esnyder@basalt esnyder]$ jikes -classpath /usr/local/lib/sablevm/classes-1.0.3 ShiftBug.java [esnyder@basalt esnyder]$ sablevm -Y ShiftBug ff000 ff0 thanks, -emile ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=607368&group_id=5523 |
|
From: <no...@so...> - 2002-09-01 00:37:03
|
Bugs item #602543, was opened at 2002-08-30 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 Category: Compilation Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) >Summary: #include <malloc.h> is a Linux-ism Initial Comment: Please wrap instances of #include <malloc.h> within #ifdef HAVE_MALLOC_H . There are two instances in the sablevm-native-library tarball. <malloc.h> is a Linux-specific thing. All the world does not use Linux, sorry :-) ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2002-08-31 20:37 Message: Logged In: YES user_id=15365 This should be fixed in upstream GNU Classpath. I will do so. Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 |
|
From: <no...@so...> - 2002-09-01 00:35:14
|
Bugs item #602543, was opened at 2002-08-30 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 Category: Compilation Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) >Assigned to: Etienne M. Gagnon (egagnon) >Summary: #include <malloc.h> is a Linux-ism Initial Comment: Please wrap instances of #include <malloc.h> within #ifdef HAVE_MALLOC_H . There are two instances in the sablevm-native-library tarball. <malloc.h> is a Linux-specific thing. All the world does not use Linux, sorry :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 |
|
From: <no...@so...> - 2002-08-30 17:27:30
|
Bugs item #602543, was opened at 2002-08-30 10:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 Category: Compilation Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: #include <malloc.h> is a Linux-ism Initial Comment: Please wrap instances of #include <malloc.h> within #ifdef HAVE_MALLOC_H . There are two instances in the sablevm-native-library tarball. <malloc.h> is a Linux-specific thing. All the world does not use Linux, sorry :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 |
|
From: <no...@so...> - 2002-08-24 15:47:12
|
Bugs item #599407, was opened at 2002-08-23 16:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=599407&group_id=5523 Category: Compilation Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: Need workaround for libffi VERSION def'n Initial Comment: Please include this patch to work around a screwup in the libffi installation: http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/sablevm/files/patch-ae?rev=1.3 ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2002-08-24 11:47 Message: Logged In: YES user_id=15365 Hi Archie! Changing the order of includes, and undefining macros was not ideal. Instead, I defined new configure macros, and refrained from using the PACKAGE and VERSION macros in C source code. Please test that sablevm 1.0.4 does effectively solve the libffi problem on BSD. Thanks, Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=599407&group_id=5523 |
|
From: <no...@so...> - 2002-08-24 15:01:22
|
Bugs item #599407, was opened at 2002-08-23 16:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=599407&group_id=5523 Category: Compilation Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) >Assigned to: Etienne M. Gagnon (egagnon) Summary: Need workaround for libffi VERSION def'n Initial Comment: Please include this patch to work around a screwup in the libffi installation: http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/sablevm/files/patch-ae?rev=1.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=599407&group_id=5523 |
|
From: <no...@so...> - 2002-08-24 15:01:22
|
Bugs item #597356, was opened at 2002-08-19 16:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597356&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Etienne M. Gagnon (egagnon) Summary: stack trace contains wrong line number Initial Comment: class LineNum { public static void main (String args[]) { try { // blank line // blank line // blank line ((Object)null).hashCode(); } catch (Exception c) { c.printStackTrace(); } } } This program prints: $ sablevm LineNum java.lang.NullPointerException at LineNum.main(LineNum.java:3) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) Notice the "LineNum.java:3" -- that should be "LineNum.java:7" instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597356&group_id=5523 |
|
From: <no...@so...> - 2002-08-24 15:01:22
|
Bugs item #597368, was opened at 2002-08-19 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Etienne M. Gagnon (egagnon) Summary: Need to workaround the x86 division bug Initial Comment: /* test that we don't get tripped up by x86 problem */ public class divtest { public static int divfunc(int x, int y) { return x/y; } public static void main(String args[]) { int i = 0x80000000; int j = -1; int k = divfunc(i,j); // x86 causes trap for no good reason System.out.println("Result is "+Integer.toHexString(k)); } } This program should output "Result is 80000000" but instead we get (when running on i386): java.lang.ArithmeticException at divtest.divfunc(divtest.java:6) at divtest.main(divtest.java:14) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) Kaffe ran into this same problem. I don't know the details but it has something to do with an x86 integer division bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 |
|
From: <no...@so...> - 2002-08-23 20:23:18
|
Bugs item #599407, was opened at 2002-08-23 13:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=599407&group_id=5523 Category: Compilation Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: Need workaround for libffi VERSION def'n Initial Comment: Please include this patch to work around a screwup in the libffi installation: http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/sablevm/files/patch-ae?rev=1.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=599407&group_id=5523 |
|
From: <no...@so...> - 2002-08-22 13:11:38
|
Bugs item #598601, was opened at 2002-08-22 00:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598601&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Etienne M. Gagnon (egagnon) Summary: Native libraries are not handled proprly Initial Comment: Version 1.0.3. The attached patch should be self-explanatory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598601&group_id=5523 |
|
From: <no...@so...> - 2002-08-22 13:10:46
|
Bugs item #598602, was opened at 2002-08-22 00:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598602&group_id=5523 >Category: Execution Problem >Group: SableVM >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Etienne M. Gagnon (egagnon) Summary: Native libraries are handled incorrectly Initial Comment: I submitted this bug already but it didn't show up and followups just return 'ERROR'. SableVM 1.0.3. This patch should be self-explanatory: --- work.orig/sablevm-1.0.3/src/libsablevm/java_lang_Runtime.c Tue Aug 6 03:27:22 2002 +++ work/sablevm-1.0.3/src/libsablevm/java_lang_Runtime.c Sun Aug 18 21:56:25 2002 @@ -254,6 +254,9 @@ (*(class_loader_info->native_library_list_tail))->name = filename; (*(class_loader_info->native_library_list_tail))->handle = handle; + class_loader_info->native_library_list_tail = + &(*(class_loader_info->native_library_list_tail))->next; + result = 1; end: ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2002-08-22 09:10 Message: Logged In: YES user_id=15365 This bug was already fixed in the CVS repository a few days ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598602&group_id=5523 |
|
From: <no...@so...> - 2002-08-22 04:41:26
|
Bugs item #598602, was opened at 2002-08-21 21:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598602&group_id=5523 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Native libraries are handled incorrectly Initial Comment: I submitted this bug already but it didn't show up and followups just return 'ERROR'. SableVM 1.0.3. This patch should be self-explanatory: --- work.orig/sablevm-1.0.3/src/libsablevm/java_lang_Runtime.c Tue Aug 6 03:27:22 2002 +++ work/sablevm-1.0.3/src/libsablevm/java_lang_Runtime.c Sun Aug 18 21:56:25 2002 @@ -254,6 +254,9 @@ (*(class_loader_info->native_library_list_tail))->name = filename; (*(class_loader_info->native_library_list_tail))->handle = handle; + class_loader_info->native_library_list_tail = + &(*(class_loader_info->native_library_list_tail))->next; + result = 1; end: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598602&group_id=5523 |
|
From: <no...@so...> - 2002-08-22 04:34:01
|
Bugs item #598601, was opened at 2002-08-21 21:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598601&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Native libraries are not handled proprly Initial Comment: Version 1.0.3. The attached patch should be self-explanatory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=598601&group_id=5523 |
|
From: <no...@so...> - 2002-08-19 20:36:01
|
Bugs item #597368, was opened at 2002-08-19 13:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Need to workaround the x86 division bug Initial Comment: /* test that we don't get tripped up by x86 problem */ public class divtest { public static int divfunc(int x, int y) { return x/y; } public static void main(String args[]) { int i = 0x80000000; int j = -1; int k = divfunc(i,j); // x86 causes trap for no good reason System.out.println("Result is "+Integer.toHexString(k)); } } This program should output "Result is 80000000" but instead we get (when running on i386): java.lang.ArithmeticException at divtest.divfunc(divtest.java:6) at divtest.main(divtest.java:14) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) Kaffe ran into this same problem. I don't know the details but it has something to do with an x86 integer division bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 |
|
From: <no...@so...> - 2002-08-19 20:27:12
|
Bugs item #597356, was opened at 2002-08-19 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597356&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: stack trace contains wrong line number Initial Comment: class LineNum { public static void main (String args[]) { try { // blank line // blank line // blank line ((Object)null).hashCode(); } catch (Exception c) { c.printStackTrace(); } } } This program prints: $ sablevm LineNum java.lang.NullPointerException at LineNum.main(LineNum.java:3) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) Notice the "LineNum.java:3" -- that should be "LineNum.java:7" instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597356&group_id=5523 |
