On May 7, 2004, at 1:13 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
... which is trashing the strings we've just made (and are in the middle of using) in build_call_func:
2925 if (!string_compare(interpreter, signature, 2926 string_from_cstring(interpreter, "cv", 0))) 2927 return F2DPTR(pcf_c_v);
(The result of string_from_cstring isn't really rooted anywhere.)
It should be on the stack or in a processor register. If that is not the
case, we got more troubles with similar code in much more locations.
Yeah, I was wondering if the stack walk should have found it. It's possible that trace_system_stack() needs to be enhanced for ppc. But I just did a bit of digging in the debugger, and it appears that (at least in the case I checked) the relevant value is on the stack where it should be, and is marked with pobject_lives() in trace_mem_block(). So something more subtle must be going on--it seems to be finding the string on the stack.
But anyway: above strings should be created as constant strings. The signature doesn't change for the whole interpreter life time and it isn't deleted.
There is still a lot of such string creation around, which doesn't use CONST_STRING yet.
Ah, yes.
Since my strings patch, we no longer allocate memory inside of string_compare, so arguably this is a bogus time to be triggering DOD. But, if we think that subsequent changes will bring back the need to allocate memory inside of a comparison operation, then we need to redo
... then we need to keep triggering a DOD run here.
build_nativecall.pl to generate build_call_func() differently,
That's a different issue. First it should use string_equal() and constant strings.
Yes.
Then we can think of turning DOD run triggering off in string_equal.
Or, we can just Parrot_block_DOD() inside of build_call_func(), to speed it up. That leaves the debugging benefit of triggering DOD inside of string_equal in other cases.
Or better create a string_equal_cstring. We are comparing
signatures here, which are just plain ASCII strings. I don't think, that
we should allow non-ASCII signatures.
I agree we should only have ASCII signatures, but it's a bit nice to be using Parrot's strings internally wherever possible.
But for the moment, we should probably leave it, to make it easier to track down why the string is being collected--that's probably the more important problem, for which this may be our only test.
JEff
