Ticket #1659 (closed bug: fixed)

Opened 4 years ago

Last modified 4 years ago

FileHandle objects don't honour timely destruction

Reported by: plobsing Owned by:
Priority: normal Milestone:
Component: none Version: 2.4.0
Severity: medium Keywords:
Cc: Language:
Patch status: applied Platform:

Description

Converting a test in t/pmc/io.t to use the OO FileHandle interface, I discovered that only filehandles opened with 'open' get timely destruction.

This fails:

pir_output_is( sprintf(<<'CODE', $temp_file), <<'OUTPUT', "timely destruction" );
.const string temp_file = '%s'
.sub main :main
    interpinfo $I0, 2    # GC mark runs
    $P0 = new ['FileHandle']
    $P0.'open'(temp_file, 'w')
        needs_destroy $P0
    print $P0, "a line\n"
    null $P0            # kill it
    sweep 0            # a lazy GC has to close the PIO
    $P0 = new ['FileHandle']
    $P0.'open'(temp_file, 'r')
    $S0 = $P0.'read'(20)
    print $S0
.end
CODE
a line
OUTPUT

Attachments

get_results_clean.patch Download (4.4 KB) - added by NotFound 4 years ago.

Change History

Changed 4 years ago by bacek

Hello.

Problem not in FileHandle PMC. In the nutshell - lazy GC doesn't work (reliably).

-- Bacek.

Changed 4 years ago by julian.notfound@…

>  Problem not in FileHandle PMC. In the nutshell - lazy GC doesn't work
>  (reliably).

Adding a sub call before the sweep the example works. So it looks like
this is another effect of the calling problem: the invocant and
arguments remain stored in the context signature after sub and method
calls until the next call or context destruction, and gets marked.


-- 
Salu2

Changed 4 years ago by NotFound

Changed 4 years ago by NotFound

The attached patch get_results_clean.patch fixes the problem by cleaning the context signature at the bottom of the get_results opcode and also fixes the tests that fails because of still using the old pcc style of get_results before invoke.

I'm not sure if this change can affect some non deprecated feature, though.

Changed 4 years ago by NotFound

  • patch set to applied

After some irc discussion, patch applied in r47476

Changed 4 years ago by NotFound

Test untodoed in r47477 after testing in i386 and amd64.

Changed 4 years ago by NotFound

  • status changed from new to closed
  • resolution set to fixed

No further reports and new release launched, closing ticket.

Note: See TracTickets for help on using tickets.