In my environment where
OS = Linux 2.0.38 #2 Sun Jan 2 11:44:53 JST 2000,
Kaffe = kaffe-1.0.6,
the following simple program does not run as expected.
It prints nothing.
$ cat TestTimeZone.java
import java.util.TimeZone;
import java.io.*;
public class TestTimeZone {
public static void m
On Wed, 11 October 2000, Jason Baker wrote:
> To clarify: gcRealloc was copying sizeof(gc_unit) many extra bytes
> from oldmem to mem. This bug is innocuous unless either:
> a. sizeof(gc_unit) (2 pointers) > the difference between the sizes
>of mem and oldmem (at least 8 bytes) (writing t
[EMAIL PROTECTED] writes:
> > As long as pointers are 4 bytes, the newly allocated object
> > has room for this junk.
To clarify: gcRealloc was copying sizeof(gc_unit) many extra bytes
from oldmem to mem. This bug is innocuous unless either:
a. sizeof(gc_unit) (2 pointers) > the difference
On Wed, 11 October 2000, Jason Baker wrote:
> Actually, kaffe uses the prev link of the gc_unit as the next *.
> You're actually seeing the next* of the following object get trashed:
> gcRealloc copies an extra sizeof(gc_unit) bytes after the original
> object.
I'll try to digest this more clo
Which OS is this?
Check that the SP_OFFSET value is correct (compile and run
developers/sp_offset.c and compare to config/sparc/youros/...h)
- Godmar
>
>
> >>> Patrick Tullmann <[EMAIL PROTECTED]> 10-Oct-00 10:00:54 PM >>>
>
> >When it seg faults, type 'bt' (for backtrace) and you'
Patrick Tullmann <[EMAIL PROTECTED]> writes:
> Kaffe's GC uses the data portion of a gc_unit to store the "next"
> pointer in a free block. Thus, if the block isn't really free, the
> "next" pointer will overlap with the first word of data in the data
> block. Or, in your case, I'm guessing th
[EMAIL PROTECTED] wrote:
> The KREALLOC at line 1876 in classMethod.c is trying to reallocate
> iface->implementors array of shorts to a size of 20. Down in gcRealloc(),
> gcRealloc() is called (line 1025) and the original memory pointed to
> by mem (which is iface->implementors of the clazz in
>
>>> Patrick Tullmann <[EMAIL PROTECTED]> 10-Oct-00 10:00:54 PM >>>
>When it seg faults, type 'bt' (for backtrace) and you'll get
>a stack backtrace.
Thanks.
Here's the stack trace produced because of the IllegalInstruction
caused by the interpreter version of Kaffe:
Starting program: /usr
Here I go again:
I am getting the following assertion failure upon executing
kaffe on my Linux/Alpha box.
Kaffe: mem/gc-mem.c:315: gc_heap_malloc: Assertion `blk->free != 0' failed.
I found that this is caused due to the value of freelist[3]->list->free->next
being set to NULL. I placed a
On Mon, 09 October 2000, Timothy Stack wrote:
> > Finally it seems like I might have fixed the
> > assertion failure that has been bothering me
> > on my Linux/Alpha box.
>
> which assert?
The one on line 315 in /kaffe/kaffevm/mem/gc-mem.c.
I do see that my supposed "fix" is not correct thanks
Nic Ferrier wrote:
> Anyone know how to get in touch with anybody from the Kopi project?
>
> I have some fixes for them and they're not answering my mails.
I had contacts in the past but no news since July :-( I have already
made some patches and I manages `egp' versions of KJC. Forward me y
11 matches
Mail list logo
