Ticket #1758 (closed bug: fixed)

Opened 6 years ago

Last modified 6 years ago

Segfault caused by new dynop mapping code

Reported by: nwellnhof Owned by:
Priority: normal Milestone:
Component: core Version: 2.6.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


When working on TT #1746, I accidentally discovered another bug. The following script causes a segfault:

.loadlib 'perl6_ops'

.HLL "perl6"

.sub "" :load :init
    load_language "perl6"
    get_hll_global $P108, ["Perl6";"Module"], "Loader"
    $P109 = "&infix:<,>"()
    $P110 = "&circumfix:<{ }>"($P109)
    set $S111, "$!storage"
    getattribute $P112, $P110, $S111
    $P108."need"("A", $P112)

You must have Rakudo installed. The PIR code tries to load a non-existant module 'A.pm' and segfaults in the exception code.

The segfault happens here:


The op_info pointer is invalid because the area it points to has been reallocated here:


It looks like this is caused by the new dynop mapping code.

Change History

Changed 6 years ago by plobsing

I am unable to reproduce the described problem either running PIR or PBC.

I am using Rakudo Perl 6, version 2010.08-46-g77a72a3 built on parrot 2.7.0 r48794, gcc/linux/amd64 both optimized and unoptimized builds.

Is the bug still there? Can it still be reproduced somehow?

Changed 6 years ago by nwellnhof

I still get the segfault everytime I run the code. Using r48809 and the latest Rakudo on 32bit Ubuntu. The program output is:

Unable to find module 'A' in the @*INC directories.
(@*INC contains:
Segmentation fault

Changed 6 years ago by plobsing

This should be fixed as of r48923.

  • The object that was being reallocated no longer exists.
  • op_info_t objects should now always come from static allocation areas.

Can you retest to confirm that this is fixed?

Changed 6 years ago by nwellnhof

Yes, it is fixed. Thanks.

Changed 6 years ago by plobsing

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.