Ticket #880 (new bug)

Opened 12 years ago

Last modified 12 years ago

class associated to namespace ["parrot";"Class"] gets overridden

Reported by: jessevdam Owned by:
Priority: normal Milestone:
Component: core Version: 1.4.0
Severity: medium Keywords:
Cc: Language:
Patch status: new Platform: all


When running the following code the the class associated to the ["parrot";"Class"] namespace gets overridden by the Foo9 class obj newclass $P1, "Foo9"

typeof $P6, $P1

$P3 = get_root_namespace ["parrot";"Class"]

$P4 = get_class $P3

print $P4

return "Foo9" instead of the expected "Class"

the function get_class in the default.pmc calls the pmc_new_init(interp, enum_class_PMCProxy, type_num); where the self object points to the Foo9 class obj.

In init_pmc in pmcproxy.pmc the interp->vtables[self->type_num = 102 in my case]->_namespace; points to the parrot;class namespace. Because this function effectually calls Parrot_PCCINVOKE(interp, interp->vtables[self->type_num]->_namespace = parrot;Class, CONST_STRING(interp, "set_class"), "P->", SELF = class of Foo9); the class associated to the parrot;Class namespace gets overridden.

I solved this problem by adding following line to init_class_from_hash in the class.pmc new_vtable->_namespace = new_namespace;

But I don't know for what reason the interp->vtables[type_num]->_namespace is different from the interp->vtables[type_num]->pmc_class->_namespace

So I do not know whether this is the right solution to this problem.

But I added a special ticket for this because there is another bug.


The test in t/pmc/objects.t fails to detect this condition because of the bug described in ticket #879. But adding a special test with the code described above would be good thing to do.

Change History

Changed 12 years ago by whiteknight

This does bring up the larger issue of consistency, there are several fields in the VTABLE structure that do not seem to be used consistently and probably need some rethinking and cleanup.

The _namespace and pmc_class are two oft-misused values. whoami and base_type can be weird too on occasion.

What we probably should do here is determine what kinds of information the VTABLE structure should cache consistently, and then encapsulate some common accesses behind a reasonable interface.

Note: See TracTickets for help on using tickets.