Ticket #1015 (new bug)
clone_p_p segfaults with self-referential Hash pmc.
Reported by: | Austin_Hastings | Owned by: | whiteknight |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | core | Version: | 1.6.0 |
Severity: | medium | Keywords: | segfault, clone, memory |
Cc: | Language: | ||
Patch status: | Platform: |
Description
If a complex data structure, built with Hash and Array structures, is self-referencing, running clone_p_p on it will quickly segfault.
our %Global_hash; sub bsu() { say("BSU: starting."); %Global_hash<key><key2> := 1; %Global_hash<key><loop> := %Global_hash; my %local := %Global_hash; my $result := Q:PIR {{ $P0 = find_lex '%local' %r = clone $P0 }}; say("BSU: returning."); return $result; } bsu();
The solution here is likely to be involved -- perhaps disabling the GC and using the mark bit to track what has been cloned. But segmentation fault is not a parrot exception, which is what a memory problem should become.
Dukeleto confirms this problem exists on Darwin, and his Linux box.
FYI: I discovered this because PCT clones the symbol table of PAST::Block nodes.
Attachments
Change History
Note: See
TracTickets for help on using
tickets.