sablevm-bugs Mailing List for SableVM
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...> - 2004-07-03 21:12:55
|
Bugs item #981658, was opened at 2004-06-28 19:53 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=981658&group_id=5523 Category: Other Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Tom Schutter (tschutter) Assigned to: Nobody/Anonymous (nobody) Summary: jni.h should use JNIIMPORT, not JNIEXPORT Initial Comment: In jni.h, the prototypes for functions such as JNI_CreateJavaVM() should be using JNIIMPORT, not JNIEXPORT. Although JNIEXPORT is an empty define on Linux, on platforms such as Windows it is defined. If an app needs to define a function pointer type for JNI_CreateJavaVM(), it needs the JNIIMPORT variant, not the JNIEXPORT variant. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 17:12 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Tracking System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=981658&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 21:11:43
|
Bugs item #925087, was opened at 2004-03-28 18:00 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=925087&group_id=5523 Category: Wishlist Group: SableVM >Status: Closed Resolution: None Priority: 1 Submitted By: Etienne M. Gagnon (egagnon) Assigned to: Nobody/Anonymous (nobody) 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: 2004-07-03 17:11 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Tracking System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=925087&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 21:09:36
|
Bugs item #692638, was opened at 2003-02-24 20:08 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=692638&group_id=5523 Category: None Group: None >Status: Closed 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 ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 17:09 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Tracking System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=692638&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 21:06:00
|
Bugs item #688939, was opened at 2003-02-18 14:26 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688939&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 1 Submitted By: Etienne M. Gagnon (egagnon) Assigned to: Etienne M. Gagnon (egagnon) Summary: Free lists (?) Initial Comment: This is more a reminder than a bug report. Todo: Verify that all elements added to free-lists are first filled with zeros (unless doing otherwise is known to be safe). In particular, JNIEnv structures should be cleared before recycling. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 17:05 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688939&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 21:03:31
|
Bugs item #688788, was opened at 2003-02-18 12:51 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688788&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: Assertion failure in prepare_code.c Initial Comment: I'm trying to use Soot with SableVM 1.0.5 and getting an assertion failure. Here is my test program: ----------------------------------------- import soot.*; import soot.jimple.*; import java.util.*; public class x { public static void main(String[] args) throws Exception { SootClass c = Scene.v().loadClassAndSupport("java.lang.String"); c.setApplicationClass(); for (Iterator i = c.methodIterator(); i.hasNext(); ) { SootMethod m = (SootMethod)i.next(); Body body = (JimpleBody)m.retrieveActiveBody(); Scene.v().getPack("jtp").apply(body); Scene.v().getPack("jop").apply(body); } } } ------------------------------------------ Note that the "java.lang.String" class that is being processed is the one that comes with SableVM. Other classes process OK but this one seems to cause problems.. perhaps there is some bytecode sequence that SableVM can't handle or is invalid? Here is the failure: $ sablevm x assertion "instruction->stack_and_local_map->stack_size >= 0" failed: file "prepare_code.c", line 1088 Abort(core dumped) ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 17:03 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688788&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 20:58:45
|
Bugs item #679970, was opened at 2003-02-03 21:27 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=679970&group_id=5523 Category: Configuration Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: MessageDigest.getInstance() fails Initial Comment: MessageDigest.getInstance("MD5") fails. There are two things that need to be fixed for this to work. (1) The file "resource/java/security/classpath.security" in the Classpath distribution needs to be installed into the /usr/local/lib/sablevm/lib/security directory during installation. I suspect there are other properties files that also need to be installed. (2) SableVM needs to define some default values for certain well-known System properties, such as "java.home", etc. See: http://java.sun.com/j2se/1.4/docs/api/java/lang/System.html#getProperties() for a list of these properties. Attached s a simple test program (stolen from kaffe). ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 16:58 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=679970&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 13:30:56
|
Bugs item #677672, was opened at 2003-01-30 14:17 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=677672&group_id=5523 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) 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: Etienne M. Gagnon (egagnon) Date: 2004-07-03 09:30 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- 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...> - 2004-07-03 13:27:53
|
Bugs item #668112, was opened at 2003-01-14 15:24 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668112&group_id=5523 Category: Other Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 09:27 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668112&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 13:25:34
|
Bugs item #668111, was opened at 2003-01-14 15:22 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668111&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 3 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: Threads are leaked Initial Comment: When a thread exits, the memory associated with the thread is not freed. In addition, the thread is not put back on the free threads list associated with the VM. So the thread and its associated memory is leaked. In addition, the finalize() method is not overridden in java.lang.Thread. Guess that would be the logical place to free the memory and/or add the thread to the free list. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 09:25 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668111&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 13:23:28
|
Bugs item #653551, was opened at 2002-12-13 20:27 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653551&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: assertion failure running soot-1.2.4 Initial Comment: I can consistently reproduce an assertion faiulre with SableVM 1.0.5. This happens on both FreeBSD and Linux. You must use the debug version of SableVM to get the assertion failure (obviously), othewise you get a SEGV core dump or other weird error. Environment: soot-1.2.4 classes are in the classpath. Contents of ~/.sablevm are attached. Also, two class files are attached, along with source files. jikes-1.15 was used to generate them. Here's the failure: $ sablevm-debug --verbose-gc soot.Main --jimple Test [verbose gc: allocating fixed size heap (2 * 16777216 bytes)] Soot started on Fri Dec 13 17:21:16 GMT-08:00 2002 [verbose gc: previously allocated 16765808 bytes, surviving 3822924 bytes, new heap is 16777216 bytes, gc time = 0 sec 87391 usec] [verbose gc: previously allocated 16767540 bytes, surviving 6648540 bytes, new heap is 16777216 bytes, gc time = 0 sec 133278 usec] Transforming Test... sablevm-debug: util2.c:161: _svmf_is_assignable_from: Assertion `T != ((void *)0)' failed. Abort I've also gotten these assertion failures instead: sablevm-debug: instructions_switch.c:15982: _svmf_interpreter: Assertion `_svmf_is_assignable_from (env, instance->vtable->type, _svmf_cast_type_class (method->class_info))' failed. sablevm: INTERNAL ERROR (source file "error.c", line 170): unhandled segmentation fault It appears that memory is being corrupted somehow. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 09:23 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- Comment By: Archie Cobbs (archiecobbs) Date: 2002-12-16 18:20 Message: Logged In: YES user_id=99943 Here is a much simpler way I've found to reproduce this problem. Just compile and run this program: public class Bar { public static void main(String[] args) { new soot.jimple.internal.JimpleLocalBox(null).setValue(null); } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653551&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 13:11:05
|
Bugs item #653360, was opened at 2002-12-13 12:45 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653360&group_id=5523 Category: Configuration Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: --enable-debug should comple w/ symbols Initial Comment: Enhancement request: The --enable-debugging configuration option should do two more things besides what it already does: (a) Add the '-g' flag to all gcc compilations so that symbols are included with all objects (b) Remove the '-s' flag from all 'install' commands so that symbols are not stripped when the libraries and binaries are installed Having symbols included makes debugging a lot easier :-) Thanks. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 09:11 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653360&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-07-03 13:07:06
|
Bugs item #597368, was opened at 2002-08-19 16:36 Message generated for change (Comment added) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 7 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. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-07-03 09:07 Message: Logged In: YES user_id=15365 This bug has been moved to the new SableVM Bug Trackiong System. Please visit: http://sablevm.org/bugs ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2003-07-27 22:13 Message: Logged In: YES user_id=694080 Hi, I did a fix for this bug. I tested it with and without signal for exception on x86. The change has been done in my *unstable* sablevm branch: /developers/belanger/sandbox/sablejit/sablevm/sablevm/ (revison 441). Basically, it can take advantage of the exception generated on x86 to avoid a check everytime. It may work with other processors, but my current patch assumes that it does not. Index: src/libsablevm/interpreter.c =================================================================== --- src/libsablevm/interpreter.c (revision 438) +++ src/libsablevm/interpreter.c (working copy) @@ -83,7 +83,28 @@ case SVM_SIGNAL_ARITHMETIC_EXCEPTION: { - goto arithmeticexception_handler; + /* + fprintf(stderr, "value1: %d value2: %d\n", + stack[stack_size - 1], + stack[stack_size]); + */ + if (stack[stack_size - 1].jint == 0x80000000 && + stack[stack_size].jint == -1) + { + /* Continue normally + * + * Note: result slot already contains value1 + */ +#if defined(_SABLEVM_INLINED_THREADED_INTERPRETER) || defined(_SABLEVM_DIRECT_TH READED_INTERPRETER) + goto *((pc++)->implementation); +#else + goto dispatch; +#endif /* defined(_SABLEVM_INLINED_THREADED_INTERPRETER) || defined(_SABLEVM_DIR ECT_THREADED_INTERPRETER) */ + } + else + { + goto arithmeticexception_handler; + } } break; Index: src/libsablevm/instructions.m4.c =================================================================== --- src/libsablevm/instructions.m4.c (revision 438) +++ src/libsablevm/instructions.m4.c (working copy) @@ -1174,7 +1174,6 @@ { env->sigfpe_expected = JNI_TRUE; } - #endif /* save pc in case exception is raised */ @@ -1187,10 +1186,40 @@ env->stack.current_frame->pc = pc; goto arithmeticexception_handler; } - #endif /* _SABLEVM_SIGNALS_FOR_EXCEPTIONS */ + + /* + * Handling of exceptional case: 0x80000000 / -1 + * + * Note: Not all processors will generate an exception. + * + */ +#if defined(_SABLEVM_SIGNALS_FOR_EXCEPTIONS) && defined(__i386__) + +#ifndef NDEBUG + if (value1 == 0x80000000 && value2 == -1) + { + env->sigfpe_expected = JNI_TRUE; + } +#endif + /* save pc in case exception is raised */ + env->stack.current_frame->pc = pc; stack[stack_size - 1].jint = value1 / value2; + +#else + + if (value1 == 0x80000000 && value2 == -1) + { + /* Nothing to do as result slot already contains value1 */ + } + else + { + stack[stack_size - 1].jint = value1 / value2; + } + +#endif /* _SABLEVM_SIGNALS_FOR_EXCEPTIONS && __i386__ */ + } m4svm_instruction_tail (); @@ -1236,7 +1265,18 @@ #endif /* _SABLEVM_SIGNALS_FOR_EXCEPTIONS */ - *((jlong *) &stack[stack_size - 2]) = value1 / value2; + /* Note: On i386 the (gcc) implementation is okay */ + /* + if (value1 == 0x8000000000000000L && value2 == -1L) + { + *((jlong *) &stack[stack_size - 2]) = value1; + } + else + */ + { + *((jlong *) &stack[stack_size - 2]) = value1 / value2; + } + } m4svm_instruction_tail (); @@ -1597,7 +1637,7 @@ if (value1 != value1 || value2 != value2) { /* NaN */ - stack[(stack_size -= 3) - 1].jint = -1; + stack[(stack_size -= 3) - 1].jint = 1; } else { ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2003-01-31 08:21 Message: Logged In: YES user_id=694080 On PPC, that division produces undefined result (on a G3, it gives -1). No exception is raised, however it would be possible to check for overflow (probably would require some inlined assembly). We may need some #define in system.c to handle it for each architecture that produces "incorrect" result. FYI, due to the asymmetry of 2's complement, there is no positive integer equal to 0x80000000 / -1. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-06-28 23:53:16
|
Bugs item #981658, was opened at 2004-06-28 23:53 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=981658&group_id=5523 Category: Other Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Schutter (tschutter) Assigned to: Nobody/Anonymous (nobody) Summary: jni.h should use JNIIMPORT, not JNIEXPORT Initial Comment: In jni.h, the prototypes for functions such as JNI_CreateJavaVM() should be using JNIIMPORT, not JNIEXPORT. Although JNIEXPORT is an empty define on Linux, on platforms such as Windows it is defined. If an app needs to define a function pointer type for JNI_CreateJavaVM(), it needs the JNIIMPORT variant, not the JNIEXPORT variant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=981658&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-28 23:01:11
|
Bugs item #704345, was opened at 2003-03-15 20:30 Message generated for change (Settings changed) made by egagnon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 Category: Wishlist Group: SableVM >Status: Deleted >Resolution: Duplicate 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: Chris Pickett (cpickett) Date: 2004-03-26 19:49 Message: Logged In: YES user_id=715646 I never got around to this, but I wouldn't mind trying it out when I prepare a few changes from my tree for migration to staging, after I have submitted an initial paper on my spmt work. Or it could serve as a good intro project to SableVM for somebody. ---------------------------------------------------------------------- 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...> - 2004-03-28 23:00:13
|
Bugs item #925087, was opened at 2004-03-28 18:00 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=925087&group_id=5523 Category: Wishlist Group: SableVM Status: Open Resolution: None Priority: 1 Submitted By: Etienne M. Gagnon (egagnon) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=925087&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-28 22:56:59
|
Bugs item #668112, was opened at 2003-01-14 15:24 Message generated for change (Settings changed) made by egagnon 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: Nobody/Anonymous (nobody) 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...> - 2004-03-28 22:56:39
|
Bugs item #677672, was opened at 2003-01-30 14:17 Message generated for change (Settings changed) made by egagnon 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: Nobody/Anonymous (nobody) 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...> - 2004-03-28 22:41:29
|
Bugs item #668113, was opened at 2003-01-14 15:24 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668113&group_id=5523 Category: Other Group: SableVM >Status: Closed 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? ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-28 17:41 Message: Logged In: YES user_id=694080 yes, it has been removed in staging. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668113&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-27 13:37:00
|
Bugs item #597368, was opened at 2002-08-19 16:36 Message generated for change (Settings changed) made by egagnon 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: 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. ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2003-07-27 22:13 Message: Logged In: YES user_id=694080 Hi, I did a fix for this bug. I tested it with and without signal for exception on x86. The change has been done in my *unstable* sablevm branch: /developers/belanger/sandbox/sablejit/sablevm/sablevm/ (revison 441). Basically, it can take advantage of the exception generated on x86 to avoid a check everytime. It may work with other processors, but my current patch assumes that it does not. Index: src/libsablevm/interpreter.c =================================================================== --- src/libsablevm/interpreter.c (revision 438) +++ src/libsablevm/interpreter.c (working copy) @@ -83,7 +83,28 @@ case SVM_SIGNAL_ARITHMETIC_EXCEPTION: { - goto arithmeticexception_handler; + /* + fprintf(stderr, "value1: %d value2: %d\n", + stack[stack_size - 1], + stack[stack_size]); + */ + if (stack[stack_size - 1].jint == 0x80000000 && + stack[stack_size].jint == -1) + { + /* Continue normally + * + * Note: result slot already contains value1 + */ +#if defined(_SABLEVM_INLINED_THREADED_INTERPRETER) || defined(_SABLEVM_DIRECT_TH READED_INTERPRETER) + goto *((pc++)->implementation); +#else + goto dispatch; +#endif /* defined(_SABLEVM_INLINED_THREADED_INTERPRETER) || defined(_SABLEVM_DIR ECT_THREADED_INTERPRETER) */ + } + else + { + goto arithmeticexception_handler; + } } break; Index: src/libsablevm/instructions.m4.c =================================================================== --- src/libsablevm/instructions.m4.c (revision 438) +++ src/libsablevm/instructions.m4.c (working copy) @@ -1174,7 +1174,6 @@ { env->sigfpe_expected = JNI_TRUE; } - #endif /* save pc in case exception is raised */ @@ -1187,10 +1186,40 @@ env->stack.current_frame->pc = pc; goto arithmeticexception_handler; } - #endif /* _SABLEVM_SIGNALS_FOR_EXCEPTIONS */ + + /* + * Handling of exceptional case: 0x80000000 / -1 + * + * Note: Not all processors will generate an exception. + * + */ +#if defined(_SABLEVM_SIGNALS_FOR_EXCEPTIONS) && defined(__i386__) + +#ifndef NDEBUG + if (value1 == 0x80000000 && value2 == -1) + { + env->sigfpe_expected = JNI_TRUE; + } +#endif + /* save pc in case exception is raised */ + env->stack.current_frame->pc = pc; stack[stack_size - 1].jint = value1 / value2; + +#else + + if (value1 == 0x80000000 && value2 == -1) + { + /* Nothing to do as result slot already contains value1 */ + } + else + { + stack[stack_size - 1].jint = value1 / value2; + } + +#endif /* _SABLEVM_SIGNALS_FOR_EXCEPTIONS && __i386__ */ + } m4svm_instruction_tail (); @@ -1236,7 +1265,18 @@ #endif /* _SABLEVM_SIGNALS_FOR_EXCEPTIONS */ - *((jlong *) &stack[stack_size - 2]) = value1 / value2; + /* Note: On i386 the (gcc) implementation is okay */ + /* + if (value1 == 0x8000000000000000L && value2 == -1L) + { + *((jlong *) &stack[stack_size - 2]) = value1; + } + else + */ + { + *((jlong *) &stack[stack_size - 2]) = value1 / value2; + } + } m4svm_instruction_tail (); @@ -1597,7 +1637,7 @@ if (value1 != value1 || value2 != value2) { /* NaN */ - stack[(stack_size -= 3) - 1].jint = -1; + stack[(stack_size -= 3) - 1].jint = 1; } else { ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2003-01-31 08:21 Message: Logged In: YES user_id=694080 On PPC, that division produces undefined result (on a G3, it gives -1). No exception is raised, however it would be possible to check for overflow (probably would require some inlined assembly). We may need some #define in system.c to handle it for each architecture that produces "incorrect" result. FYI, due to the asymmetry of 2's complement, there is no positive integer equal to 0x80000000 / -1. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-27 09:12:01
|
Bugs item #668271, was opened at 2003-01-14 21:16 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668271&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed 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. ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-27 04:11 Message: Logged In: YES user_id=694080 Fixed in staging r1884. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668271&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-27 09:03:02
|
Bugs item #704526, was opened at 2003-03-16 10:29 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 Category: Wishlist Group: SableVM >Status: Closed Resolution: None Priority: 2 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: bytecode numbering Initial Comment: Hi, The instructions in constants.h correspond to the JVM spec bytecode numbering up until 201, after which point all instructions are SableVM-specific instructions. Is this ordering used to parse class files? If so, then the SableVM-specific instructions should start at 256. There are two reasons: 1) Sun may expand the bytecode set in the future, at which point it will be necessary to renumber things anyway. 2) I would like to use the "impdep1" and possibly "impdep2" opcodes, which have numbers 254 and 255. I want to transform a class file to have impdep1 / impdep2 opcodes using Soot, and so if this same ordering is really the ordering used to parse class files (I think it is), then I need those spots to be free. Currently, I am redefining PUTFIELD_INT and PUTFIELD_LONG from 254 and 255 to 333 and 334 respectively, but it is cleaner if everything is shifted down to start at 256. If this change is okay, I can make a patch with the renumbered instructions. Cheers, Chris ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-27 04:02 Message: Logged In: YES user_id=694080 I will close it then... David ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2004-03-26 19:45 Message: Logged In: YES user_id=715646 Feel free to close this Etienne. We can't have gap in the instruction constants without changing the code to initialize the instructions array. It doesn't matter: if Sun introduces new bytecodes, we can just bump everything up then. As for what I wanted to do, I took something similar to the JikesRVM approach and use dummy methods in Spmt.class, inserted ahead-of-time by a Soot transformer, and turn these into as many SableVM instructions as I need at runtime (and the code runs on normal VM's). ---------------------------------------------------------------------- Comment By: Chris Pickett (ihatemcgill) Date: 2003-03-16 11:54 Message: Logged In: YES user_id=630752 Okay, I can do that. However, I still think the constants should be renumbered. I was going to use impdep1 to fork a speculative thread, with an address of the bytecode at which to start the execution. So, if I used attributes, I would pass the locations in the code array at which to insert SableVM-only bytecodes to the VM, and then they would get inserted during code preparation. This way, there are an unlimited number of bytecodes I can play with (although I think I only need two). I just thought it would be easier to get things working with the impdep1/impdep2 bytecodes. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:21 Message: Logged In: YES user_id=15365 Be warned that the official SableVM source base will not deviate from the JVM specification by accepting bytecodes other than those specified by the JVM specification. You should consider using attributes, instead, as custom attributes are supported by the JVM specification, and probably allow you to achieve your goal of communicating extra information to the VM. One big advantage of the attribute approach is that your class files remain executable under other JVMs, which is a good thing to detect any invalid bytecode sequence Soot might generate (by running the class under a JVM with a bytecode verifier). Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-27 09:00:46
|
Bugs item #723743, was opened at 2003-04-18 12:24 Message generated for change (Settings changed) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=723743&group_id=5523 Category: Execution Problem Group: None >Status: Closed 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 ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 21:35 Message: Logged In: YES user_id=694080 Works fine. Will assume that it has been fixed. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=723743&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-27 08:59:58
|
Bugs item #923922, was opened at 2004-03-26 10:03 Message generated for change (Settings changed) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=923922&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: Laurent Martelli (laurentmartelli) Assigned to: Nobody/Anonymous (nobody) Summary: Runtime.addShutdownHook: NullPointerException Initial Comment: java.lang.ExceptionInInitializerError at java.lang.VMClass.initialize (VMClass.java:140) at java.lang.Class.initialize (Class.java:163) at java.lang.reflect.Method.invokeNative (Method.java) at java.lang.reflect.Method.invoke (Method.java:552) at org.objectweb.jac.core.JacLoader.run (JacLoader.java:570) at org.objectweb.jac.core.Jac.main (Jac.java:321) at java.lang.VirtualMachine.invokeMain (VirtualMachine.java) at java.lang.VirtualMachine.main (VirtualMachine.java:88) Caused by: java.lang.NullPointerException at java.lang.Thread.isAlive (Thread.java:601) at java.lang.Runtime.addShutdownHook (Runtime.java:351) at org.objectweb.jac.core.ACManager.static{} (ACManager.java:89) at java.lang.VMClass.step8 (VMClass.java) at java.lang.VMClass.initialize (VMClass.java:126) ...7 more ACManager reads: static { Runtime.getRuntime().addShutdownHook( new Thread() { public void run() { if (acManager!=null) { logger.info("JAC system shutdown: notifying all ACs..."); acManager.onExit(); } logger.info("Bye bye."); } } ); } Changig Thread.javaline 601 to be like this: return vmThread != null && vmThread.isAlive(); fixes the problem for me. ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 21:27 Message: Logged In: YES user_id=694080 This has now been fixed in staging. David ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 16:56 Message: Logged In: YES user_id=694080 Hi, This is the correct fix. I also fixed a similar bug. The fixes will get into SableVM/staging branch later today. Thank you for reporting this bug. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=923922&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-27 02:35:12
|
Bugs item #723743, was opened at 2003-04-18 12:24 Message generated for change (Comment added) made by davidbelanger 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 ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 21:35 Message: Logged In: YES user_id=694080 Works fine. Will assume that it has been fixed. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=723743&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-27 02:27:42
|
Bugs item #923922, was opened at 2004-03-26 10:03 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=923922&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Laurent Martelli (laurentmartelli) Assigned to: Nobody/Anonymous (nobody) Summary: Runtime.addShutdownHook: NullPointerException Initial Comment: java.lang.ExceptionInInitializerError at java.lang.VMClass.initialize (VMClass.java:140) at java.lang.Class.initialize (Class.java:163) at java.lang.reflect.Method.invokeNative (Method.java) at java.lang.reflect.Method.invoke (Method.java:552) at org.objectweb.jac.core.JacLoader.run (JacLoader.java:570) at org.objectweb.jac.core.Jac.main (Jac.java:321) at java.lang.VirtualMachine.invokeMain (VirtualMachine.java) at java.lang.VirtualMachine.main (VirtualMachine.java:88) Caused by: java.lang.NullPointerException at java.lang.Thread.isAlive (Thread.java:601) at java.lang.Runtime.addShutdownHook (Runtime.java:351) at org.objectweb.jac.core.ACManager.static{} (ACManager.java:89) at java.lang.VMClass.step8 (VMClass.java) at java.lang.VMClass.initialize (VMClass.java:126) ...7 more ACManager reads: static { Runtime.getRuntime().addShutdownHook( new Thread() { public void run() { if (acManager!=null) { logger.info("JAC system shutdown: notifying all ACs..."); acManager.onExit(); } logger.info("Bye bye."); } } ); } Changig Thread.javaline 601 to be like this: return vmThread != null && vmThread.isAlive(); fixes the problem for me. ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 21:27 Message: Logged In: YES user_id=694080 This has now been fixed in staging. David ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 16:56 Message: Logged In: YES user_id=694080 Hi, This is the correct fix. I also fixed a similar bug. The fixes will get into SableVM/staging branch later today. Thank you for reporting this bug. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=923922&group_id=5523 |