sablevm-bugs Mailing List for SableVM (Page 3)
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: SourceForge.net <no...@so...> - 2003-06-30 23:42:23
|
Bugs item #752846, was opened at 2003-06-11 15:27 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=752846&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: bootstrap - long is J Initial Comment: Small typo in bootstrap.m4.c. Long has signature type J not L. See patch attached. Problems occur with a method declared with a long[] arg in main class. public void foo(long[] a) { } but not always. It is very difficult too reproduce. David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2003-06-30 19:42 Message: Logged In: YES user_id=694080 This has been fixed in my developer version. .../belanger/sandbox/sablevm* David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=752846&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-06-30 23:30:40
|
Bugs item #757425, was opened at 2003-06-19 14:42 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=757425&group_id=5523 Category: Execution Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: bug in File.c Initial Comment: Function Java_java_io_File_listInternal is returning null when the directory is empty. The Java specification specifies that it should return an empty array. Note: I did not check if it was fixed in a more recent version of Classpath. Simply removing these lines should fix it: /* Did we find anything? */ if (i == 0) { free (filelist); return (0); } David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2003-06-30 19:30 Message: Logged In: YES user_id=694080 There is also appears to be a memory leak as filelist is not freed on successful returns. I fixed both this bug and the memory leak in my developer branch: ..../belanger/sandbox/sablevm* David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=757425&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-06-19 18:42:43
|
Bugs item #757425, was opened at 2003-06-19 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=757425&group_id=5523 Category: Execution Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: bug in File.c Initial Comment: Function Java_java_io_File_listInternal is returning null when the directory is empty. The Java specification specifies that it should return an empty array. Note: I did not check if it was fixed in a more recent version of Classpath. Simply removing these lines should fix it: /* Did we find anything? */ if (i == 0) { free (filelist); return (0); } David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=757425&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-06-12 22:12:22
|
Bugs item #753040, was opened at 2003-06-11 22:58 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=753040&group_id=5523 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: f2i with large integers Initial Comment: Converting a float that has a value larger than the largest int to an int does not always give the largest int as specified in the specification. public class BugF2I { public static int f2i(float v) { return (int) v; } public static void main(String[] args) { System.out.println(Integer.MAX_VALUE); System.out.println(f2i(Integer.MAX_VALUE + 1.0f)); System.out.println((int) 7777779123.32f); System.out.println(f2i(7777779123.32f)); } } Note: Compiled with jikes on ppc and with javac on x86. jikes / sablevm / ppc 2147483647 2147483647 -812155392 2147483647 jikes / sablevm / x86 2147483647 -2147483648 -812155392 -2147483648 jikes / java / x86 2147483647 2147483647 -812155392 2147483647 javac / java / x86 2147483647 2147483647 2147483647 2147483647 javac / sablevm / x86 2147483647 -2147483648 2147483647 -2147483648 javac / sablevm / ppc 2147483647 2147483647 2147483647 2147483647 David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2003-06-12 18:12 Message: Logged In: YES user_id=694080 Hi, I upgrade jikes to 1.18 (there was some other bug in 1.15) and it fixed also this problem on jikes / sablevm / ppc. It may be a jikes 1.15 bug, I tried again with javac / sablevm / x86 (though on a different machine) and I got the right result this time. To summarize, jikes 1.15 appears to have problems evaluating constant expression with floating points at compile time (constant folding) that were fixed in later versions. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=753040&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-06-12 02:58:14
|
Bugs item #753040, was opened at 2003-06-11 22:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=753040&group_id=5523 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: f2i with large integers Initial Comment: Converting a float that has a value larger than the largest int to an int does not always give the largest int as specified in the specification. public class BugF2I { public static int f2i(float v) { return (int) v; } public static void main(String[] args) { System.out.println(Integer.MAX_VALUE); System.out.println(f2i(Integer.MAX_VALUE + 1.0f)); System.out.println((int) 7777779123.32f); System.out.println(f2i(7777779123.32f)); } } Note: Compiled with jikes on ppc and with javac on x86. jikes / sablevm / ppc 2147483647 2147483647 -812155392 2147483647 jikes / sablevm / x86 2147483647 -2147483648 -812155392 -2147483648 jikes / java / x86 2147483647 2147483647 -812155392 2147483647 javac / java / x86 2147483647 2147483647 2147483647 2147483647 javac / sablevm / x86 2147483647 -2147483648 2147483647 -2147483648 javac / sablevm / ppc 2147483647 2147483647 2147483647 2147483647 David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=753040&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-06-11 19:27:06
|
Bugs item #752846, was opened at 2003-06-11 15:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=752846&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: bootstrap - long is J Initial Comment: Small typo in bootstrap.m4.c. Long has signature type J not L. See patch attached. Problems occur with a method declared with a long[] arg in main class. public void foo(long[] a) { } but not always. It is very difficult too reproduce. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=752846&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-05-11 20:14:26
|
Bugs item #736139, was opened at 2003-05-11 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&group_id=5523 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: class loader memory manager Initial Comment: The class loader memory manager seems to have 2 problems. I noticed that the class_loader_info->memory_block_list is empty for some class loaders. This is what explains it: 1) _svmf_init_cl_alloc does not seem to be called for other class loaders than the bootstrap class loader. However, I did not try to locate the code that should call it. 2) new memory blocks allocated via malloc are not added to the memory_block_list. The patch included fixes the 2nd problem. Note that it also fixes somewhat the first problem, the list being empty, a new block (the first allocated block) is allocated and added to the list. Note: This is a quick patch and it should be reviewed/modified before integrating it. Note: The patch also fixes a typo in a comment. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-04-18 16:24:25
|
Bugs item #723743, was opened at 2003-04-18 18:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=723743&group_id=5523 Category: Execution Problem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bonniot (bonniot) Assigned to: Nobody/Anonymous (nobody) Summary: loadClass fails on custom class loader Initial Comment: When I try to load a class from a custom URLClassLoader, it fails with a null pointer exception. Note that this only happens if the class is not on the main classpath. $ cat Test.java import java.net.URL; import java.io.File; class Test { public static void main(String[] args) { try { ClassLoader loader = new java.net.URLClassLoader (new URL[]{ new File("/tmp").getCanonicalFile().toURL() }); Class c = loader.loadClass(args[0]); System.out.println(c); } catch (Throwable t) { t.printStackTrace(); } } } $ cat Simple.java public class Simple {} $ javac Simple.java $ mv Simple.class /tmp/ $ sablevm Test Simple SableVM version 1.0.8 Copyright (C) 2000-2002 Etienne M. Gagnon <eti...@uq...> and others. All rights reserved. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. To get the name of all copyright holders and detailed license information, type "sablevm --license" or look in the directory "/usr/share/sablevm". The SableVM web site is located at http://www.sablevm.org/ . java.lang.NullPointerException at java.net.URLClassLoader.getPermissions(URLClassLoader.java:488) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:84) at java.net.URLClassLoader.findClass(URLClassLoader.java:317) at java.lang.ClassLoader.loadClass(ClassLoader.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:259) at Test.main(Test.java:10) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) $ java Test Simple class Simple ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=723743&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-04-01 20:23:58
|
Bugs item #713515, was opened at 2003-04-01 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=713515&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: freed global ref not set to NULL Initial Comment: _svmm_free_native_ref(env, jobject obj) does set obj to NULL but does not set *obj to NULL before putting them on the free list. This will cause _svmm_new_native_ref(env, jobject obj) to return some global ref such that *obj != NULL leading to an assertion failure in _svmf_initialize_fields if native refs in some cases. The suggested fix is to set *obj to NULL in _svmm_new_native_ref if it is taken from the free list. Patch is done against CVS 2003-03-17 (rel 1.0.8). David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2003-04-01 15:38 Message: Logged In: YES user_id=694080 The patch doesn't seem to have been attached? I'm trying again. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=713515&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-04-01 20:20:03
|
Bugs item #713515, was opened at 2003-04-01 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=713515&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: freed global ref not set to NULL Initial Comment: _svmm_free_native_ref(env, jobject obj) does set obj to NULL but does not set *obj to NULL before putting them on the free list. This will cause _svmm_new_native_ref(env, jobject obj) to return some global ref such that *obj != NULL leading to an assertion failure in _svmf_initialize_fields if native refs in some cases. The suggested fix is to set *obj to NULL in _svmm_new_native_ref if it is taken from the free list. Patch is done against CVS 2003-03-17 (rel 1.0.8). David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=713515&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-24 03:25:42
|
Bugs item #704345, was opened at 2003-03-15 20:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 Category: Wishlist Group: SableVM Status: Open Resolution: None Priority: 1 Submitted By: Chris Pickett (ihatemcgill) >Assigned to: Etienne M. Gagnon (egagnon) Summary: optimization of method preparation Initial Comment: In Ch.2 of his thesis, Etienne explains the code preparation technique to replace slow instructions that must check for class initialization with faster ones (patching in code from the end of the code array at runtime). However, once a class is initialized, then for future preparation of methods that use this class, it is unnecessary to have either the slow version or the patch. The only cost of this optimization is an extra check at method preparation time for each instruction that requires class initialization, to see if the class has already been initialized. The savings are that 1) neither patching code nor slow initialization code needs to be prepared 2) there is no patching that ever takes place for that instruction and 3) (most importantly), we save at least one synchronization on the slow initialization instruction. This optimization is applicable to all three threading modes, but it will of course be most interesting to see if it improves inlined-threading. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:24 Message: Logged In: YES user_id=15365 Hi Chris, You are highly encouraged to submit a patch as attachment to this bug. :-) Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-24 03:25:17
|
Bugs item #677672, was opened at 2003-01-30 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=677672&group_id=5523 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) >Assigned to: Archie Cobbs (archiecobbs) Summary: VM does not check for array alloc overflow Initial Comment: Here is the bug: $ cat ArrayOverflow.java public class ArrayOverflow { public static void main(String[] args) { double[] array = new double[0x20000000]; array[0x1000000] = 1.0; } } $ sablevm ArrayOverflow sablevm: INTERNAL ERROR (source file "error.c", line 86): unexpected segmentation fault Abort(core dumped) The problem is that when allocating the array, SableVM does not check for 32 bit overflow. In this example, the array length fits within 32 bits but the array length multiplied by the size of each array element does not. As a result, the total size overflows (to zero!) and a zero length array is allocated. SableVM should verify that the total array size does not overflow a "size_t" variable (SIZE_T_MAX). ---------------------------------------------------------------------- Comment By: Archie Cobbs (archiecobbs) Date: 2003-03-03 12:32 Message: Logged In: YES user_id=99943 System.arraycopy() has a similar bug. I suspect there are other places where array bounds don't check that off + length > 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=677672&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-24 03:25:16
|
Bugs item #668113, was opened at 2003-01-14 15:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668113&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) >Assigned to: Archie Cobbs (archiecobbs) Summary: _svmt_interned_string is unused Initial Comment: It doesn't appear that the '_svmt_interned_string' type is used anywhere. Can it be removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668113&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-24 03:25:16
|
Bugs item #668112, was opened at 2003-01-14 15:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668112&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) >Assigned to: Archie Cobbs (archiecobbs) Summary: _svmt_bootstrap_classloader_struct.current_class_file Initial Comment: It seems like the 'current_class_file' field of the 'struct _svmt_bootstrap_classloader_struct' structure is unnecessary, as it's only used in _svmf_bootcl_derive_class(), and there's no way that this function can be called recursively with 'current_class_file' non-empty, so it could be replaced with a local variable in that function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668112&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-24 03:25:16
|
Bugs item #668271, was opened at 2003-01-14 21:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668271&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) >Assigned to: Archie Cobbs (archiecobbs) >Summary: vm-&gt;threads.array is one entry too short Initial Comment: The vm->threads.array array is allocated with SVM_MAX_THREAD_ID entries. in the array. However, it's possible for entry #SVM_MAX_THREAD_ID to be used (see Java_java_lang_Thread_nativeStart). Entry zero is not used of course. So SVM_MAX_THREAD_ID + 1 entries should be allocated instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668271&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-24 03:22:24
|
Bugs item #692638, was opened at 2003-02-24 20:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=692638&group_id=5523 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) >Assigned to: David Bélanger (davidbelanger) Summary: bug jni getFieldID and others Initial Comment: Hi, I'm not a JNI expert but from what I understand GetFieldID (file: native_interface.m4.c) should return NULL on error and then the programmer knows he/she should check for any exception raised. However, it does not always return NULL on error because of this conditional: if (field == NULL || _svmf_is_set_flag (field->access_flags, SVM_ACC_STATIC)) { _svmf_error_NoSuchFieldError (env); goto end; } Field may be non-null and the 2nd expr may be true. So a non-null field id is returned. Suggested fix: if (field == NULL || _svmf_is_set_flag (field->access_flags, SVM_ACC_STATIC)) { _svmf_error_NoSuchFieldError (env); + field = NULL; goto end; } Functions affected: Get{Field,Method}ID GetStatic{Field,Method}ID and maybe others David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=692638&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-24 03:21:08
|
Bugs item #705868, was opened at 2003-03-18 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Chris Pickett (cpickett) >Assigned to: Chris Pickett (cpickett) Summary: multiprocessor crashes Initial Comment: SableVM still segfaults on a multiprocessor, even with fixes for yield() and _svmf_set_current_env(). However, now execution completes 50% of the time. Attached are parallel and non-parallel matrix multiply benchmarks. For non-parallel: java matmul N where N is the size of matrix and for parallel: java matmul_p N P where P is the number of processors. There are no problems on uniprocessors. Cheers, Chris ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-22 14:54 Message: Logged In: YES user_id=15365 Note: I assume you already know that multi-processor support is in SableVM's future enhancement list, not its current feature list... :-) It would be nice if you could identify the problem more precisely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-23 01:08:37
|
Bugs item #694790, was opened at 2003-02-27 20:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=694790&group_id=5523 Category: Execution Problem Group: SablePath >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel Bonniot (bonniot) Assigned to: Etienne M. Gagnon (egagnon) Summary: Incorrect NullPointerException in java.io.File.listFiles Initial Comment: The following code fails at runtime, while it works with Sun's java 1.3 and gij. The code just tries to list the files in an empty, but existing directory: import java.io.*; class Bug { public static void main(String[] args) { File f = new File("/tmp/Empty"); f.listFiles(); } } Make sure /tmp/Empty is an existing, empty directory. $ javac Bug.java $ java Bug $ sablevm Bug SableVM version 1.0.6 Copyright (C) 2000-2002 Etienne M. Gagnon <eti...@uq...> and others. All rights reserved. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. To get the name of all copyright holders and detailed license information, type "sablevm --license" or look in the directory "/usr/share/sablevm". The SableVM web site is located at http://www.sablevm.org/ . java.lang.NullPointerException at java.io.File.listFiles(File.java:1289) at java.io.File.listFiles(File.java:1259) at Bug.main(Bug.java:8) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=694790&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-22 19:43:42
|
Bugs item #705868, was opened at 2003-03-18 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None >Priority: 3 Submitted By: Chris Pickett (cpickett) Assigned to: Nobody/Anonymous (nobody) Summary: multiprocessor crashes Initial Comment: SableVM still segfaults on a multiprocessor, even with fixes for yield() and _svmf_set_current_env(). However, now execution completes 50% of the time. Attached are parallel and non-parallel matrix multiply benchmarks. For non-parallel: java matmul N where N is the size of matrix and for parallel: java matmul_p N P where P is the number of processors. There are no problems on uniprocessors. Cheers, Chris ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-22 14:54 Message: Logged In: YES user_id=15365 Note: I assume you already know that multi-processor support is in SableVM's future enhancement list, not its current feature list... :-) It would be nice if you could identify the problem more precisely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-22 19:42:32
|
Bugs item #705868, was opened at 2003-03-18 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None >Priority: 5 Submitted By: Chris Pickett (cpickett) Assigned to: Nobody/Anonymous (nobody) Summary: multiprocessor crashes Initial Comment: SableVM still segfaults on a multiprocessor, even with fixes for yield() and _svmf_set_current_env(). However, now execution completes 50% of the time. Attached are parallel and non-parallel matrix multiply benchmarks. For non-parallel: java matmul N where N is the size of matrix and for parallel: java matmul_p N P where P is the number of processors. There are no problems on uniprocessors. Cheers, Chris ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-22 14:54 Message: Logged In: YES user_id=15365 Note: I assume you already know that multi-processor support is in SableVM's future enhancement list, not its current feature list... :-) It would be nice if you could identify the problem more precisely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-22 19:19:46
|
Bugs item #707799, was opened at 2003-03-21 19:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=707799&group_id=5523 >Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Rejected >Priority: 1 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Etienne M. Gagnon (egagnon) Summary: heap size test condition Initial Comment: In the file "gc_copying.c" on line 45, the test condtion is: if (vm->heap.allocation_increment == 0 && (2 * vm->heap.min_size) < vm->heap.min_size) I think it should be if (vm->heap.allocation_increment == 0 && (2 * vm->heap.min_size) < vm->heap.max_size) ^ i.e. replace min_size by max_size. ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-22 14:32 Message: Logged In: YES user_id=15365 Here, SableVM is testing that the multiplication 2*min_size does not overflow (unsigned integer). max_size is not involved. I agree: this needs a comment. But, I already don't like this way of testing for overflow. Any suggestion for a clean way to detect unsigned multiplication is welcome that does not involve using 64-bit values. In summary, it's not a bug. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-21 19:11 Message: Logged In: NO by Anatole ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=707799&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-21 23:58:26
|
Bugs item #707799, was opened at 2003-03-21 16:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=707799&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: heap size test condition Initial Comment: In the file "gc_copying.c" on line 45, the test condtion is: if (vm->heap.allocation_increment == 0 && (2 * vm->heap.min_size) < vm->heap.min_size) I think it should be if (vm->heap.allocation_increment == 0 && (2 * vm->heap.min_size) < vm->heap.max_size) ^ i.e. replace min_size by max_size. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-21 16:11 Message: Logged In: NO by Anatole ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=707799&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-21 23:58:01
|
Bugs item #707799, was opened at 2003-03-21 16:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=707799&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: heap size test condition Initial Comment: In the file "gc_copying.c" on line 45, the test condtion is: if (vm->heap.allocation_increment == 0 && (2 * vm->heap.min_size) < vm->heap.min_size) I think it should be if (vm->heap.allocation_increment == 0 && (2 * vm->heap.min_size) < vm->heap.max_size) ^ i.e. replace min_size by max_size. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=707799&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-18 21:55:08
|
Bugs item #704533, was opened at 2003-03-16 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 Category: Wishlist Group: SableVM >Status: Closed >Resolution: Wont Fix Priority: 2 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: types should end in _t for better syntax highlighting Initial Comment: Change _svmt_* to _svmt_*_t for better syntax highlighting in all C files. It really is *much* more readable, even if there's an extra "_t". ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-18 17:07 Message: Logged In: YES user_id=15365 Chris decided to investigate how to fix highlighting in emacs. So I'm closing the bug. Etienne ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-18 16:41 Message: Logged In: YES user_id=15365 So, now that you have found an alternate solution, can I go and close the bug as "Won't fix" ? I personally don't like the _t suffix much. We already have a longer than enough prefix for types... Etienne ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2003-03-18 11:42 Message: Logged In: YES user_id=715646 Or, as David suggested, figure out how to change emacs syntax coloring. Personally, this is a better solution, because then things like jint, jvalue, etc. can get colored. Cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2003-03-16 14:40 Message: Logged In: YES user_id=715646 in libsablevm: emacs RET M-x dired RET RET % m ^[_a-zA-Z0-9]*\.[_a-zA-Z0-9\.]*$ RET Q _svmt_[_a-zA-Z0-9\$]* RET \&_t RET ! -----> hold down the key until finished. now in jnidefs.h and types.h M-x replace-string RET struct_t RET struct RET C-x C-s RET y RET .............. that should be it. probably want to repeat the same thing in libsablevm/include -- emacs lets you scroll through a history of commands using the up arrow, or you can just cut and paste from this message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-18 21:28:52
|
Bugs item #704533, was opened at 2003-03-16 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 Category: Wishlist Group: SableVM Status: Open >Resolution: Out of Date Priority: 2 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: types should end in _t for better syntax highlighting Initial Comment: Change _svmt_* to _svmt_*_t for better syntax highlighting in all C files. It really is *much* more readable, even if there's an extra "_t". ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-18 16:41 Message: Logged In: YES user_id=15365 So, now that you have found an alternate solution, can I go and close the bug as "Won't fix" ? I personally don't like the _t suffix much. We already have a longer than enough prefix for types... Etienne ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2003-03-18 11:42 Message: Logged In: YES user_id=715646 Or, as David suggested, figure out how to change emacs syntax coloring. Personally, this is a better solution, because then things like jint, jvalue, etc. can get colored. Cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2003-03-16 14:40 Message: Logged In: YES user_id=715646 in libsablevm: emacs RET M-x dired RET RET % m ^[_a-zA-Z0-9]*\.[_a-zA-Z0-9\.]*$ RET Q _svmt_[_a-zA-Z0-9\$]* RET \&_t RET ! -----> hold down the key until finished. now in jnidefs.h and types.h M-x replace-string RET struct_t RET struct RET C-x C-s RET y RET .............. that should be it. probably want to repeat the same thing in libsablevm/include -- emacs lets you scroll through a history of commands using the up arrow, or you can just cut and paste from this message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 |
