From @LLFourn

# Exporter1.pm
multi foo { }

sub EXPORT {
  Hash.new('&foo' => &foo) #Map.new doesn't cause it.
}

# Exporter2.pm
multi foo is export { }

# main.pl
use Exporter1;
use Exporter2;

#! Segmentation fault

confirmed on both debian and OS X with​:

2015.10-145-g9979bf2 built on MoarVM version 2015.10-42-g73c0269

From @nwc10

On Tue, Nov 03, 2015 at 04​:18​:44AM -0800, Lloyd Fournier wrote​:

# New Ticket Created by Lloyd Fournier
# Please include the string​: [perl #​126551]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126551 >

# Exporter1.pm
multi foo { }

sub EXPORT {
Hash.new('&foo' => &foo) #Map.new doesn't cause it.
}
---
# Exporter2.pm
multi foo is export { }
---
# main.pl
use Exporter1;
use Exporter2;

#! Segmentation fault

Score!

=================================================================
==13267==ERROR​: AddressSanitizer​: heap-buffer-overflow on address 0x60300023e2c8 at pc 0x7fa2e35f4498 bp 0x7fff11d85020 sp 0x7fff11d85018
READ of size 8 at 0x60300023e2c8 thread T0
  #​0 0x7fa2e35f4497 in get_attribute src/6model/reprs/P6opaque.c​:224
  #​1 0x7fa2e34c413c in MVM_interp_run src/core/interp.c​:2462
  #​2 0x7fa2e37602a3 in MVM_vm_run_file src/moar.c​:249
  #​3 0x401a4f in main src/main.c​:191
  #​4 0x7fa2e2cebd5c in __libc_start_main (/lib64/libc.so.6+0x1ed5c)
  #​5 0x401058 (/home/nicholas/Sandpit/moar-san/bin/moar+0x401058)

0x60300023e2c8 is located 8 bytes to the left of 24-byte region [0x60300023e2d0,0x60300023e2e8)
allocated by thread T0 here​:
  #​0 0x7fa2e406a62f in __interceptor_malloc ../../.././libsanitizer/asan/asan_malloc_linux.cc​:72
  #​1 0x7fa2e367c6b5 in MVM_malloc src/core/alloc.h​:2
  #​2 0x7fa2e368fce7 in deserialize_stable src/6model/serialization.c​:2413
  #​3 0x7fa2e369208d in work_loop src/6model/serialization.c​:2601
  #​4 0x7fa2e369291f in MVM_serialization_demand_stable src/6model/serialization.c​:2671
  #​5 0x7fa2e3679afd in MVM_sc_get_stable src/6model/sc.c​:234
  #​6 0x7fa2e368dba0 in read_object_table_entry src/6model/serialization.c​:2114
  #​7 0x7fa2e3693c86 in repossess src/6model/serialization.c​:2832
  #​8 0x7fa2e3694f41 in MVM_serialization_deserialize src/6model/serialization.c​:2990
  #​9 0x7fa2e34db5f6 in MVM_interp_run src/core/interp.c​:3466
  #​10 0x7fa2e37602a3 in MVM_vm_run_file src/moar.c​:249
  #​11 0x401a4f in main src/main.c​:191
  #​12 0x7fa2e2cebd5c in __libc_start_main (/lib64/libc.so.6+0x1ed5c)

SUMMARY​: AddressSanitizer​: heap-buffer-overflow src/6model/reprs/P6opaque.c​:224 get_attribute
Shadow bytes around the buggy address​:
  0x0c068003fc00​: 00 00 00 02 fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x0c068003fc10​: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00
  0x0c068003fc20​: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c068003fc30​: 00 00 00 06 fa fa 00 00 00 06 fa fa 00 00 00 06
  0x0c068003fc40​: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
=>0x0c068003fc50​: 00 fa fa fa 00 00 00 fa fa[fa]00 00 00 fa fa fa
  0x0c068003fc60​: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x0c068003fc70​: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
  0x0c068003fc80​: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
  0x0c068003fc90​: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x0c068003fca0​: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes)​:
  Addressable​: 00
  Partially addressable​: 01 02 03 04 05 06 07
  Heap left redzone​: fa
  Heap right redzone​: fb
  Freed heap region​: fd
  Stack left redzone​: f1
  Stack mid redzone​: f2
  Stack right redzone​: f3
  Stack partial redzone​: f4
  Stack after return​: f5
  Stack use after scope​: f8
  Global redzone​: f9
  Global init order​: f6
  Poisoned by user​: f7
  Contiguous container OOB​:fc
  ASan internal​: fe
==13267==ABORTING

Not a NULL pointer dereference. A more serious bug than that.

Thanks for reporting the bug, and thanks for reducing it down to a really
small case.

Nicholas Clark

The RT System itself - Status changed from 'new' to 'open'

From @nwc10

On Tue, Nov 03, 2015 at 05​:31​:40PM +0000, Nicholas Clark wrote​:

Not a NULL pointer dereference. A more serious bug than that.

Also present with MoarVM/NQP/Rakudo at

47bb37e Include \r\n synthetic in default separators.
7710de0 Fix thinko in \r\n -> grapheme prep.
385850b Streamline Range.iterator

so it existed before the recent serialisation format changes.

Nicholas Clark