Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Am Dienstag, 5. Dezember 2006 20:39 schrieb Matt Diephouse:
> The portion of the assertion that
> fails is
>
> !(((s)->obj.flags) & b_PObj_on_free_list_FLAG
>
> which means that this string has been garbage collected. I saw a
> couple different instances of this problem and in all of them, the
> string in question was a constant (some were C-level and others were
> PIR-level).
>
> So the underlying problem is that constant strings are getting
> collected when they shouldn't.
constants reside, when correctly created, in different object pools than
GC-able items (constant_pmc_pool, constant_string_header_pool). PMCs in the
constant_pmc_pool are marked during GC. No constant pool item is swept during
GC, i.e the are only collect on interpreter shutdown.
Constant PMCs are marked, but are constant STRINGs?
If above assert triggers, then some item are created in the wrong pool and
then stored as constants.
To track that further down, it'll be helpful to have some information about
the origin & contents of the GC-ed constant, but typically such creation code
is in imcc or packfile.
I'm on my laptop atm and it's not exhibiting the error, but the
constant in question was in a method call:
$P0.'method'('string constant that was getting collected', ...)
--
Matt Diephouse
http://matt.diephouse.com
