Jeff Clites <[EMAIL PROTECTED]> wrote: > 1707 # if ! DISABLE_GC_DEBUG > 1708 /* It's easy to forget that string comparison can trigger > GC */ > 1709 if (GC_DEBUG(interpreter)) > 1710 Parrot_do_dod_run(interpreter, DOD_trace_stack_FLAG); > 1711 # endif
> Basically, when running with --gc-debug, we trigger a DOD run inside of > string_compare, Yep. > ... 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. 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. > 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. Then we can think of turning DOD run triggering off in string_equal. 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. > JEff leo
