hi,
I've been working on a small rewrite of the JAR file code in
kaffe/kaffevm/jar.* and I have some questions. The new code is mostly
just a cleanup of the older stuff, the directory entries are read a
little faster and the entries are stored in a hash table instead of a
linked list. The
sballard@rainbow:~/kaffe$ jar tvf /usr/share/java/gnujsp.jar
java.lang.UnsatisfiedLinkError: Failed to locate native function:
java/util/zip/Inflater.init(Z)V
at kaffe.util.zip.SwitchInflater.init(SwitchInflater.java:23)
at
hi,
I've run into an odd problem that I don't know quite how to fix.
Basically, a stack overflow isn't handled particularly well, especially
when there are class loaders involved. Since we execute a good deal of
code to throw the exception it eats up even more stack and we risk going
past the
hi,
I don't know if this is a real bug or not, but in java.util.TreeMap
there's this line in deleteNode:
325:x.parent = y.parent;
The problem is that x can be NIL which is a global variable, which seems
bad. One might think a quick fix would be to test for NIL and not set
I think this is OK because NIL.parent is never actually used.
I believe it does though, at the end of deleteNode it calls deleteFixup
with `x', which could be NIL. Then in deleteFixup it performs the
following check, x == x.parent.left. In fact, if you add a check for NIL
in delete node
bah, my original reply seems to have vanished...
Running this code shows that deleteFixup() is indeed often
called with x == NIL; however, that doesn't seem to cause
any problems.
Hmm... but there are lines in deleteFixup which change the color of the
parent:
393:
Hmm.. here is the code that TreeMap.java was based on:
http://wannabe.guru.org/alg/node21.html
If there is a problem, then it should have the same bug.
I'll look at it more...
Running this code shows that deleteFixup() is indeed often
called with x == NIL; however, that doesn't seem
I've checked in that patch.. but here's a question. Why doesn't
kaffe (with the old TreeMap) run out of memory when the program
below is run? Maybe just chance?
TreeMap t = new TreeMap();
for (int i = 0; i 1000; i++) {
Integer value
Finally it seems like I might have fixed the
assertion failure that has been bothering me
on my Linux/Alpha box.
which assert?
In gcRealloc():kaffe/kaffevm/mem/gc-incremental.c
line 1026 it looks like the size of memcpy should
be size instead of osize. If the osize (original/old
size ?)
howdy,
So, as you might've seen we just released a new version of the JanosVM,
which is a modded version of Kaffe. For the most part we haven't changed
much in the original code base, but there have been a number of fixes and
added features that would be nice to port back to Kaffe.
On Monday 18 March 2002 21:47, Jim Pick wrote:
On Mon, Mar 18, 2002 at 12:55:30PM -0700, Timothy Stack wrote:
I can provide a diff between a recent Kaffe and JanosVM, so it will
mostly be a matter of pulling out the good stuff and ignoring the rest.
Good stuff. I'll definitely take
- Solve random SEGV on NetBSD/PowerPC.
I don't know. Could someone verify if it has been solved?
- Solve random (and hard to reproduce) SEGV on FreeBSD/Intel.
I haven't found anything in the ChangeLog about it. Could anyone provide more
information?
I assume they both refer to
12 matches
Mail list logo
