sablevm-bugs Mailing List for SableVM (Page 6)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-bugs — SableVM bugs mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(16) |
Sep
(10) |
Oct
|
Nov
(2) |
Dec
(7) |
| 2003 |
Jan
(14) |
Feb
(11) |
Mar
(59) |
Apr
(3) |
May
(1) |
Jun
(7) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(26) |
Apr
|
May
|
Jun
(1) |
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2003-02-18 19:18:03
|
Bugs item #688939, was opened at 2003-02-18 14:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688939&group_id=5523 Category: Execution Problem Group: SableVM Status: Open 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688939&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-02-18 19:14:35
|
Bugs item #688936, was opened at 2003-02-18 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688936&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Etienne M. Gagnon (egagnon) Assigned to: Etienne M. Gagnon (egagnon) Summary: Missing call to _svmf_set_current_env Initial Comment: While starting a new thread (in _svmf_thread_start), _svmf_set_current_env should be called to store the _svmt_JNIEnv pointer in the a thread-specific global variable. As it stands, now, when a signal handler is activated on any thread other than the main thread, SableVM aborts complaining about an unhandled signal in error.c line 170. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688936&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-02-18 17:43:44
|
Bugs item #688788, was opened at 2003-02-18 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688788&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: 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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688788&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-02-16 01:54:31
|
Bugs item #663270, was opened at 2003-01-06 11:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: [jni: fatal error (Local reference capacity exceeded)] Initial Comment: I'm trying to run an application that uses Soot. If I try to process too many classfiles at once, I get this error plus a core dump: [jni: fatal error (Local reference capacity exceeded)] This makes SableVM suddenly look like a "toy" Java VM when we know it's really better than that :-) SableVM should handle this situation more gracefully, even if it means an 'escape' mechanism that's slower than normal or whatever. ---------------------------------------------------------------------- >Comment By: Archie Cobbs (archiecobbs) Date: 2003-02-15 18:02 Message: Logged In: YES user_id=99943 I think the 'correct' way to fix this is: - Implement the JNI method EnsureCapacity() - In sablevm.c, call (*env)->EnsureCapacity() to guarantee there will be at least as many local native references available as there are parameters to main(). ---------------------------------------------------------------------- Comment By: Archie Cobbs (archiecobbs) Date: 2003-01-11 17:30 Message: Logged In: YES user_id=99943 Note: this happens if you give Sablevm more than 12 arguments on the command line. For example: $ sablevm 1 2 3 4 5 6 7 8 9 10 11 12 13 [jni: fatal error (Local reference capacity exceeded)] This seems like a real bug, rather than an JNI limitation or Classpath screwup.. (?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-02-04 02:21:03
|
Bugs item #679970, was opened at 2003-02-03 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=679970&group_id=5523 Category: Configuration Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) 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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=679970&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-31 13:16:35
|
Bugs item #597368, was opened at 2002-08-19 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597368&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Etienne M. Gagnon (egagnon) Summary: Need to workaround the x86 division bug Initial Comment: /* test that we don't get tripped up by x86 problem */ public class divtest { public static int divfunc(int x, int y) { return x/y; } public static void main(String args[]) { int i = 0x80000000; int j = -1; int k = divfunc(i,j); // x86 causes trap for no good reason System.out.println("Result is "+Integer.toHexString(k)); } } This program should output "Result is 80000000" but instead we get (when running on i386): java.lang.ArithmeticException at divtest.divfunc(divtest.java:6) at divtest.main(divtest.java:14) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) Kaffe ran into this same problem. I don't know the details but it has something to do with an x86 integer division bug. ---------------------------------------------------------------------- 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-01-30 19:11:56
|
Bugs item #677672, was opened at 2003-01-30 11:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=677672&group_id=5523 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: 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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=677672&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-22 16:44:52
|
Bugs item #672241, was opened at 2003-01-21 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=672241&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed Resolution: None Priority: 5 Submitted By: David Bélanger (davidbelanger) >Assigned to: Etienne M. Gagnon (egagnon) Summary: user native libs Initial Comment: Attempting to load a native library in a class that was not loaded by the bootstrap class loader generates a segmentation fault. The native library list is not check for emptiness in Java_java_lang_Runtime_nativeLoad(). The patch included fix that problem. ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-01-22 11:48 Message: Logged In: YES user_id=15365 The correct fix is to initialize correctly the tail list pointer. This have been fixed in CVS. Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=672241&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-22 04:05:44
|
Bugs item #672241, was opened at 2003-01-21 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=672241&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: user native libs Initial Comment: Attempting to load a native library in a class that was not loaded by the bootstrap class loader generates a segmentation fault. The native library list is not check for emptiness in Java_java_lang_Runtime_nativeLoad(). The patch included fix that problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=672241&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-15 02:13:48
|
Bugs item #668271, was opened at 2003-01-14 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668271&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: vm->threads.array is one entry too short Initial Comment: The vm->threads.array array is allocated with SVM_MAX_THREAD_ID entries. in the array. However, it's possible for entry #SVM_MAX_THREAD_ID to be used (see Java_java_lang_Thread_nativeStart). Entry zero is not used of course. So SVM_MAX_THREAD_ID + 1 entries should be allocated instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668271&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-14 20:22:05
|
Bugs item #668113, was opened at 2003-01-14 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668113&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: _svmt_interned_string is unused Initial Comment: It doesn't appear that the '_svmt_interned_string' type is used anywhere. Can it be removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668113&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-14 20:21:33
|
Bugs item #668112, was opened at 2003-01-14 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668112&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: 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...> - 2003-01-14 20:20:19
|
Bugs item #668111, was opened at 2003-01-14 12:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668111&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668111&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-12 01:28:06
|
Bugs item #663270, was opened at 2003-01-06 11:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: [jni: fatal error (Local reference capacity exceeded)] Initial Comment: I'm trying to run an application that uses Soot. If I try to process too many classfiles at once, I get this error plus a core dump: [jni: fatal error (Local reference capacity exceeded)] This makes SableVM suddenly look like a "toy" Java VM when we know it's really better than that :-) SableVM should handle this situation more gracefully, even if it means an 'escape' mechanism that's slower than normal or whatever. ---------------------------------------------------------------------- >Comment By: Archie Cobbs (archiecobbs) Date: 2003-01-11 17:30 Message: Logged In: YES user_id=99943 Note: this happens if you give Sablevm more than 12 arguments on the command line. For example: $ sablevm 1 2 3 4 5 6 7 8 9 10 11 12 13 [jni: fatal error (Local reference capacity exceeded)] This seems like a real bug, rather than an JNI limitation or Classpath screwup.. (?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-01-06 19:15:41
|
Bugs item #663270, was opened at 2003-01-06 11:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: [jni: fatal error (Local reference capacity exceeded)] Initial Comment: I'm trying to run an application that uses Soot. If I try to process too many classfiles at once, I get this error plus a core dump: [jni: fatal error (Local reference capacity exceeded)] This makes SableVM suddenly look like a "toy" Java VM when we know it's really better than that :-) SableVM should handle this situation more gracefully, even if it means an 'escape' mechanism that's slower than normal or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 |
|
From: <no...@so...> - 2003-01-02 02:02:35
|
Bugs item #660598, was opened at 2002-12-31 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 Category: Execution Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) >Summary: String.getBytes("UTF8") is broken Initial Comment: There is a bug in the class gnu/java/io/encode/Encoder.java. If a String has a non-zero offset into its char[] array then things get screwey. The attached file UTF8.java demonstrates the bug. It generates this output: $ sablevm UTF8 bytes.length=20 bytes: 61 62 63 64 31 32 33 34 0 0 0 0 0 0 0 0 0 0 0 0 Other possibilities include the first byte being zero (!). ---------------------------------------------------------------------- >Comment By: Archie Cobbs (archiecobbs) Date: 2003-01-01 18:03 Message: Logged In: YES user_id=99943 Previous patch is incomplete, new patch added. I've also submitted this bug to the classpath.org bug db. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 |
|
From: <no...@so...> - 2003-01-01 03:22:38
|
Bugs item #660598, was opened at 2002-12-31 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 Category: Execution Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) >Summary: String.getBytes("UTF8") is broken Initial Comment: There is a bug in the class gnu/java/io/encode/Encoder.java. If a String has a non-zero offset into its char[] array then things get screwey. The attached file UTF8.java demonstrates the bug. It generates this output: $ sablevm UTF8 bytes.length=20 bytes: 61 62 63 64 31 32 33 34 0 0 0 0 0 0 0 0 0 0 0 0 Other possibilities include the first byte being zero (!). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 |
|
From: <no...@so...> - 2003-01-01 03:21:18
|
Bugs item #660598, was opened at 2002-12-31 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 Category: Execution Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) >Summary: String.getBytes("UTF8") is broken Initial Comment: There is a bug in the class gnu/java/io/encode/Encoder.java. If a String has a non-zero offset into its char[] array then things get screwey. The attached file UTF8.java demonstrates the bug. It generates this output: $ sablevm UTF8 bytes.length=20 bytes: 61 62 63 64 31 32 33 34 0 0 0 0 0 0 0 0 0 0 0 0 Other possibilities include the first byte being zero (!). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 |
|
From: <no...@so...> - 2003-01-01 03:20:10
|
Bugs item #660598, was opened at 2002-12-31 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 Category: Execution Problem Group: SablePath Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: String.getBytes("UTF8") is broken Initial Comment: There is a bug in the class gnu/java/io/encode/Encoder.java. If a String has a non-zero offset into its char[] array then things get screwey. The attached file UTF8.java demonstrates the bug. It generates this output: $ sablevm UTF8 bytes.length=20 bytes: 61 62 63 64 31 32 33 34 0 0 0 0 0 0 0 0 0 0 0 0 Other possibilities include the first byte being zero (!). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 |
|
From: <no...@so...> - 2002-12-16 23:20:41
|
Bugs item #653551, was opened at 2002-12-13 17:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653551&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: 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: Archie Cobbs (archiecobbs) Date: 2002-12-16 15: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: <no...@so...> - 2002-12-14 01:32:31
|
Bugs item #653460, was opened at 2002-12-13 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653460&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) >Summary: propery "sablevm.stack.size.max" ignored Initial Comment: There is no check for a thread's stack growing beyond the value set by the sablevm.stack.size.max property. See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653460&group_id=5523 |
|
From: <no...@so...> - 2002-12-14 01:27:18
|
Bugs item #653551, was opened at 2002-12-13 17:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653551&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653551&group_id=5523 |
|
From: <no...@so...> - 2002-12-13 21:10:03
|
Bugs item #653460, was opened at 2002-12-13 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653460&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: propery "sablevm.stack.size.max" ignored Initial Comment: There is no check for a thread's stack growing beyond the value set by the sablevm.stack.size.max property. See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653460&group_id=5523 |
|
From: <no...@so...> - 2002-12-13 17:45:27
|
Bugs item #653360, was opened at 2002-12-13 09:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653360&group_id=5523 Category: Configuration Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653360&group_id=5523 |
|
From: <no...@so...> - 2002-12-12 01:43:26
|
Bugs item #652416, was opened at 2002-12-11 17:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=652416&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Nobody/Anonymous (nobody) Summary: Minor optimization for new object alloc. Initial Comment: Why not this patch? memset() is often a lot faster than loops, as the compiler may know how to optimize specially for it... if so this patch should speed up every new object allocation. --- src/libsablevm/gc_copying.c.orig Tue Dec 10 11:51:13 2002 +++ src/libsablevm/gc_copying.c Tue Dec 10 11:51:34 2002 @@ -1054,14 +1054,7 @@ return JNI_ERR; } - { - size_t i; - - for (i = 0; i < instance_size; i++) - { - ((char *) result)[i] = 0; - } - } + memset(result, 0, instance_size); *pinstance = result; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=652416&group_id=5523 |
