Simon Glover <[EMAIL PROTECTED]> writes:
> Test number 6 in io.t is failing on a number of the tinderboxes with
> a double-free error.
>
> Test 6 does this:
>
> open P0, "temp.file", "<"
> clone P1, P0
> read S0, P1, 1024
> print S0
> end
>
> And the clone function in the ParrotIO vtable does this:
>
> void clone (PMC *dest) {
> VTABLE_init(INTERP, dest);
> --> /* For now both PMCs refer to the same ParrotIO object.
> * If we have different IO layers, we might copy these structures
> */
> PMC_data(dest) = PMC_data(SELF);
> dest->cache.struct_val = SELF->cache.struct_val;
> }
>
> (pay particular attention to the line with the arrow)
Yes your analysis is correct.
Fixing the clone-call to make a deep copy of the io is simple. The
hard part with this are the standard handles. The actual solution
shares one PIO with many PMCs. This triggers the same kind of bugs.
Solution is to move the standard-handles also to PMCs. This has funny
side effects on initialisation order (memory system must be up before
the IOsystem gets initialised) and in destruction (The standard
handles shouldn't get autoclosed. The patch for this will hit the list
in several hours, unless I find another sleeping monster.
> I would guess that we're getting the double-free because we're assuming
> that ParrotIO PMCs point at distinct objects, but I don't have time to
> track this down any further tonight, so I'm posting this to the list
> before I forget...
Thanks for the analysis
bye
boe
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
