[kaffe] Re: Destroyed strings...

Timothy Stack stack at cs.utah.edu
Wed Jun 5 13:30:02 PDT 2002

> Godmar wrote:
> > The string with the dead char array should at this point already be
> > scheduled for destruction.  So one possible way would be to take the
> > gc_lock and block on intern() if the mustfree is not empty.
> That seems like it might work...
> > A quick hack would be to destroy all strings first then the rest,
> > this way a string would always be destroyed before its char[]
> > object.
> Hmmm... actually, we could pretty easily have two mustfree lists.  One
> for objects with "destroy" methods, and one for all the other objects.
> That would accomplish the ordering without too much magic required in
> finishGC.
> Its not pretty, though.

Don't we still having the same problem with a second thread though:

thread    action
U1        s = io.readLine(); // reads "FooBar"
GC        STOPWORLD();
GC        puts interned "FooBar" on mustfree list.
U1        s.intern();
GC        stringDestory("FooBar");

Now U1 has a pointer to something thats been freed...  right?  Maybe i'm
missing something.

> Given that we know what's happening, I've been surprised by the fact
> that I can't come up with a test case that causes this problem on
> existing Kaffe, or other engines.  I'd have more faith in a fix for
> this problem if there was a test case that caused the problem on more
> installations of Kaffe than just the 
> interp-debug-with-per-JNI-method-exceptions-patch....
> Let me know if you can come up with a test case that tickles this
> problem....

seems impossible to make something reliable here...

> -Pat


More information about the kaffe mailing list