On Wed May 07 03:13:18 2008, [email protected] wrote:
> Digging a little further into the consequences of null_lib_name.patch,
> I see trouble ahead if the new library PMC is cloned into another
> interpreter.
>
> The fix lets you create a library PMC with no '_lib_name' property,
> but src/dynext.c:Parrot_clone_lib_into assumes that every library
> PMC has one. It causes a 'Null PMC access in get_string()'
> exception when it tries to clone the non-existent '_lib_name' prop.
>
> Is there a reason why Parrot_clone_lib_into wants to copy a hard-coded
> set of string properties? What is the intended use of the '_lib_name'
> property? No code in parrot currently touches it except to store
> it in new library PMCs and to copy it when cloning them. Maybe
> we should clone it conditionally, just as null_lib_name.patch creates
> it conditionally? Either that, or make sure that every library PMC
> always does have a '_lib_name' property.
>
> Tom
>
Parrot no longer segfaults on the following code, updated from the
original post.
.sub _ :main
null $S0
loadlib $P0, $S0
.end
Since the original problem has been fixed I'm marking this ticket as
resolved.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
