sablevm-bugs Mailing List for SableVM (Page 2)
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-03-27 00:49:21
|
Bugs item #704345, was opened at 2003-03-15 20:30 Message generated for change (Comment added) made by cpickett 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: 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-27 00:45:38
|
Bugs item #704526, was opened at 2003-03-16 10:29 Message generated for change (Comment added) made by cpickett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 Category: Wishlist Group: SableVM Status: Open 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: 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 00:40:05
|
Bugs item #705868, was opened at 2003-03-18 15:58 Message generated for change (Comment added) made by cpickett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed 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: Chris Pickett (cpickett) Date: 2004-03-26 19:40 Message: Logged In: YES user_id=715646 I tested it and this was the _svmf_enter_object_monitor () bug fixed by r1596 in staging. ---------------------------------------------------------------------- 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...> - 2004-03-26 22:42:27
|
Bugs item #736139, was opened at 2003-05-11 16:14 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&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: 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 ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:42 Message: Logged In: YES user_id=694080 This bug also is fixed in staging. David ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:38 Message: Logged In: YES user_id=694080 This bug also is fixed in staging. David ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:36 Message: Logged In: YES user_id=694080 This bug also is fixed in staging. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:42:17
|
Bugs item #780035, was opened at 2003-07-30 02:52 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=780035&group_id=5523 Category: Configuration Problem Group: SablePath >Status: Closed Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) >Assigned to: David Bélanger (davidbelanger) Summary: Making SableVM less GNU/Linux specific Initial Comment: 2 things to make SableVM less GNU/Linux specific: 1) SablePath assumes that the native libs names end with .so. However, on Mac OS X they end with .dylib. And on Windows, they will probably end with .dll. Doing symbolic links on OS X will work. However, the Java code is supposed to change it to a system-dependent name (Runtime.loadLibrary). load (path + "lib" + libname + "-" + getSableVMVersion() + ".so"); I guess there could be a getNativeLibSuffix(). Suggestions on how to get this info from autoconf are welcome. 2) Replace: find | grep ... with find . | grep ... in the build script, section to build class. SunOS, Mac OS X and FreeBSD find will complain if find has no argument. David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:42 Message: Logged In: YES user_id=694080 1) Was added. Actually dlopened lib have the .so extension on OS X. But code is in place for Windows or other non-Unix arch. 2) This is no longer relevant, scripts have been removed. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=780035&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:38:12
|
Bugs item #736139, was opened at 2003-05-11 16:14 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&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: 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 ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:38 Message: Logged In: YES user_id=694080 This bug also is fixed in staging. David ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:36 Message: Logged In: YES user_id=694080 This bug also is fixed in staging. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:36:05
|
Bugs item #736139, was opened at 2003-05-11 16:14 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&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: 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 ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:36 Message: Logged In: YES user_id=694080 This bug also is fixed in staging. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=736139&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:07:13
|
Bugs item #778648, was opened at 2003-07-27 19:17 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=778648&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: dcmpg bug Initial Comment: dcmpg does not give the right result when at least one operand is NaN. It should return 1 instead of -1. It has been fixed my stable development branch: http://svn.sablevm.org:7467/viewcvs/developers/belanger/sandbox/sablevm/ Christian Arcand deserves some credit as this bug was found by running the test cases he developed. David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:07 Message: Logged In: YES user_id=694080 The fix has been moved to staging a long time ago also. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=778648&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:04:27
|
Bugs item #790752, was opened at 2003-08-18 15:18 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=790752&group_id=5523 Category: Execution Problem Group: SableVM Status: Closed Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: David Bélanger (davidbelanger) Summary: reading pass the end of array Initial Comment: In function _svmf_fix_line_number_table (file: prepare_code.c), 4 bytes are read passed the end of the array. see patch attached David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:04 Message: Logged In: YES user_id=694080 This one also has been fixed and is in staging. David ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:03 Message: Logged In: YES user_id=694080 This one also has been fixed and is in staging. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=790752&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:04:20
|
Bugs item #787160, was opened at 2003-08-12 01:09 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=787160&group_id=5523 Category: Execution Problem Group: SablePath >Status: Closed Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) >Assigned to: David Bélanger (davidbelanger) Summary: buffer overflow in getDefaultTimeZoneId Initial Comment: There is a buffer overflow that occurs in java_util_TimeZone.c, function Java_java_util_TimeZone_getDefaultTimeZoneId on Mac OS X. I think the timezone info is incorrectly computed, leading to a string longer than the buffer. In any case, snprintf should have been used instead of sprintf. The same problem may occur on other platforms. David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:04 Message: Logged In: YES user_id=694080 This one has been fixed in CP a long time ago and is also in staging. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=787160&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:03:18
|
Bugs item #790752, was opened at 2003-08-18 15:18 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=790752&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) >Assigned to: David Bélanger (davidbelanger) Summary: reading pass the end of array Initial Comment: In function _svmf_fix_line_number_table (file: prepare_code.c), 4 bytes are read passed the end of the array. see patch attached David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2004-03-26 17:03 Message: Logged In: YES user_id=694080 This one also has been fixed and is in staging. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=790752&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2004-03-26 22:02:25
|
Bugs item #713515, was opened at 2003-04-01 15:34 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=713515&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) >Assigned to: David Bélanger (davidbelanger) 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: 2004-03-26 17:02 Message: Logged In: YES user_id=694080 This has been fixed some time ago and it is in staging. 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...> - 2004-03-26 21:57:01
|
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 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-26 17:03:02
|
Bugs item #923922, was opened at 2004-03-26 16:03 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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=923922&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-08-18 19:18:02
|
Bugs item #790752, was opened at 2003-08-18 15:18 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=790752&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: reading pass the end of array Initial Comment: In function _svmf_fix_line_number_table (file: prepare_code.c), 4 bytes are read passed the end of the array. see patch attached David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=790752&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-08-12 05:23:26
|
Bugs item #787160, was opened at 2003-08-12 01:09 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=787160&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: buffer overflow in getDefaultTimeZoneId Initial Comment: There is a buffer overflow that occurs in java_util_TimeZone.c, function Java_java_util_TimeZone_getDefaultTimeZoneId on Mac OS X. I think the timezone info is incorrectly computed, leading to a string longer than the buffer. In any case, snprintf should have been used instead of sprintf. The same problem may occur on other platforms. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=787160&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 07:05:56
|
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: Closed >Resolution: Fixed 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-07-30 03:05 Message: Logged In: YES user_id=694080 Fixed in release 1.0.9. ---------------------------------------------------------------------- Comment By: David Bélanger (davidbelanger) Date: 2003-06-30 19:43 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 ---------------------------------------------------------------------- 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-07-30 07:02:49
|
Bugs item #763667, was opened at 2003-07-01 00:01 Message generated for change (Comment added) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=763667&group_id=5523 Category: Execution Problem Group: SablePath >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: Method.invoke bug Initial Comment: Just want to add it to this bug system. This bug has already been mentionned in the mailing list. It is also fixed in my developer directory (..../belanger/sandbox/sablevm*). For more info see: http://sourceforge.net/mailarchive/forum.php?thread_id=2619671&forum_id=4154 David ---------------------------------------------------------------------- >Comment By: David Bélanger (davidbelanger) Date: 2003-07-30 03:02 Message: Logged In: YES user_id=694080 Fixed in release 1.0.9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=763667&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 06:59:09
|
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: Closed >Resolution: Fixed 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-07-30 02:59 Message: Logged In: YES user_id=694080 Bug was fixed in release 1.0.9. ---------------------------------------------------------------------- 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-07-30 06:52:23
|
Bugs item #780035, was opened at 2003-07-30 02:52 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=780035&group_id=5523 Category: Configuration Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) Assigned to: Nobody/Anonymous (nobody) Summary: Making SableVM less GNU/Linux specific Initial Comment: 2 things to make SableVM less GNU/Linux specific: 1) SablePath assumes that the native libs names end with .so. However, on Mac OS X they end with .dylib. And on Windows, they will probably end with .dll. Doing symbolic links on OS X will work. However, the Java code is supposed to change it to a system-dependent name (Runtime.loadLibrary). load (path + "lib" + libname + "-" + getSableVMVersion() + ".so"); I guess there could be a getNativeLibSuffix(). Suggestions on how to get this info from autoconf are welcome. 2) Replace: find | grep ... with find . | grep ... in the build script, section to build class. SunOS, Mac OS X and FreeBSD find will complain if find has no argument. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=780035&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-07-28 02:13:21
|
Bugs item #597368, was opened at 2002-08-19 16:36 Message generated for change (Comment added) made by davidbelanger 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. ---------------------------------------------------------------------- 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...> - 2003-07-27 23:17:10
|
Bugs item #778648, was opened at 2003-07-27 19:17 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=778648&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: dcmpg bug Initial Comment: dcmpg does not give the right result when at least one operand is NaN. It should return 1 instead of -1. It has been fixed my stable development branch: http://svn.sablevm.org:7467/viewcvs/developers/belanger/sandbox/sablevm/ Christian Arcand deserves some credit as this bug was found by running the test cases he developed. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=778648&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-07-01 04:05:17
|
Bugs item #763667, was opened at 2003-07-01 00:01 Message generated for change (Settings changed) made by davidbelanger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=763667&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: Method.invoke bug Initial Comment: Just want to add it to this bug system. This bug has already been mentionned in the mailing list. It is also fixed in my developer directory (..../belanger/sandbox/sablevm*). For more info see: http://sourceforge.net/mailarchive/forum.php?thread_id=2619671&forum_id=4154 David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=763667&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-07-01 04:01:36
|
Bugs item #763667, was opened at 2003-07-01 00:01 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=763667&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: Method.invoke bug Initial Comment: Just want to add it to this bug system. This bug has already been mentionned in the mailing list. It is also fixed in my developer directory (..../belanger/sandbox/sablevm*). For more info see: http://sourceforge.net/mailarchive/forum.php?thread_id=2619671&forum_id=4154 David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=763667&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-06-30 23:43:57
|
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:43 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 ---------------------------------------------------------------------- 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 |
