I wrote:
(*) InternHog seems to fail in the (non-optimized) interp-debug builds
now. Of course, I can't get it to fail when run under GDB... Bah!
I'll keep poking at that one.
This is very bizarre.
As far as I can tell, it only happens in interp+debug (static or not),
with the patch I just
On Tue, 4 Jun 2002, Patrick Tullmann wrote:
- * XXX variable declarations in macros are nasty.
+ * Each BEGIN_EXCEPTION_HANDLING macro must be matched by an
+ * END_EXCEPTION_HANDLING macro call in the same scope. Each should
+ * be used only once in a given JNI entrypoint.
+ *
+ * Yes,
Gwenole wrote:
On Tue, 4 Jun 2002, Patrick Tullmann wrote:
- * XXX variable declarations in macros are nasty.
+ * Each BEGIN_EXCEPTION_HANDLING macro must be matched by an
+ * END_EXCEPTION_HANDLING macro call in the same scope. Each should
+ * be used only once in a given JNI
Hi!
I have a slight problem with newer CVS versions of kaffe and JNI (both 1.06 and
1.07-rc1).
After I configure and install kaffe, I can't get it to work with my JNI programs.
It keeps complaining that it cannot find the shared library I have created. I have set
CLASSPATH as well as
Hi!
I have a slight problem with newer CVS versions of kaffe and JNI (both
1.06 and 1.07-rc1). After I configure and install kaffe, I can't get it
to work with my JNI programs. It keeps complaining that it cannot find
the shared library I have created. I have set CLASSPATH as well as
I wrote:
(*) InternHog seems to fail in the (non-optimized) interp-debug builds
now. Of course, I can't get it to fail when run under GDB... Bah!
I'll keep poking at that one.
This is very bizarre.
i can replicate it here.
Kaffe seg-faults in string.c:stringCompare, when its passed
Not sure if the fix is valid. If they can be freed before the string,
then you'd have to avoid dereferencing all interned strings here...
fyi, I hacked hashtab.c to avoid the deep comparison when removing a
value. Now, it will just check the pointers and fail instead of also
trying the
hi,
I attached a patch for SHA1PRNG.java, it still wasn't quite doing what it
was supposed to. Also, i think i forgot to mention that this was based on
Classpath's (broken) code, so the copyright should probably be gpl'ed.
oops, i whiffed again...
in
On Tue, 4 Jun 2002, Martin Edlund wrote:
I have a slight problem with newer CVS versions of kaffe and JNI (both
1.06 and 1.07-rc1).
[...]
It keeps complaining that it cannot find the shared library I
have created. I have set CLASSPATH as well as LD_LIBRARY_PATH to point
to '.' in order to
I want to run kaffe in my program in linux. I'd like to start
kaffe as a thread in a process. After kaffe finishes, it will be
requested to restart as a thread in the same process. However,
the second time I run kaffe, it does not work. It seems kaffe is
designed to run once
Also, to unintern the string you don't have to access its content
(or do you?) Isn't that what Tim suggested?
Hmm... I can't see how that avoids the fundamental problem of a live
object with a pointer to dead space.
If I have a String sitting in the hashtable that is dead, but not
Patrick Tullmann writes:
Yes. The string isn't walked anymore by the time it's destroyed,
the char array could already be gone.
Ah, okay. I'm also amazed that this hasn't cropped up before, and
still refuses to crop up with the other builds of Kaffe... Very odd.
Anyone want to come
12 matches
Mail list logo
