> 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 up with a worst-case test case that generates lots and lots of strings that all have the same hash code? Would a better solution to the hacks in hashtab or stringCompare be to make the string's array of chars an explicitly allocated/deallocted sub-object? Then the stringDestroy method could free the char array and we'd avoid this whole race condition. Strings aren't allowed to ever export their char-array, because that could violate their immutability. Right? Do strings sometimes share underlying char arrays? That would make the explicit alloc/dealloc scheme more difficult, too. -Pat ----- ----- ---- --- --- -- - - - - - Pat Tullmann [EMAIL PROTECTED] Sleep required by the average person is just five more minutes. _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe