Ticket #1758 (closed bug: fixed)

Opened 11 years ago

Last modified 11 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 11 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 11 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 11 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 11 years ago by nwellnhof

Yes, it is fixed. Thanks.

Changed 11 years ago by plobsing

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