On 03/19/2015 10:14 AM, Nicholas Clark wrote:
On Wed, Mar 18, 2015 at 05:13:54AM -0700, David Hoekman wrote:
Thanks for the concise and interesting bug report.
There might be a whole bunch more things that break in a similar way...
perl6-m -e 'say [max] 1..(1+2**15)'
arg flag is empty in slurpy positional
in sub infix:<max> at src/gen/m-CORE.setting:2181
in sub at src/gen/m-CORE.setting:20740
in block <unit> at -e:1
$ ./perl6-m -Ilib -e 'say [max] 1..(1+2**15)'
ASAN:SIGSEGV
=================================================================
==1476==ERROR: AddressSanitizer: SEGV on unknown address 0x000000040000 (pc
0x7fa75096588a sp 0x7fffda54e0e0 bp 0x7fffda54e210 T0)
#0 0x7fa750965889 in flatten_args src/core/args.c:711
#1 0x7fa75095aff7 in MVM_args_checkarity src/core/args.c:140
#2 0x7fa750979e30 in MVM_interp_run src/core/interp.c:573
#3 0x7fa750bf4f8b in MVM_vm_run_file src/moar.c:210
#4 0x4019bf in main src/main.c:189
#5 0x7fa750267d5c in __libc_start_main (/lib64/libc.so.6+0x1ed5c)
#6 0x400fc8 (/home/nicholas/Sandpit/moar-san/bin/moar+0x400fc8)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV src/core/args.c:711 flatten_args
==1476==ABORTING
and a non-ASAN build under valgrind reports
==17316==
==17316== Invalid write of size 8
==17316== at 0x4F4D91B: flatten_args (args.c:711)
==17316== by 0x4F4A427: MVM_args_checkarity (args.c:140)
==17316== by 0x4F54721: MVM_interp_run (interp.c:573)
==17316== by 0x5039D5C: MVM_vm_run_file (moar.c:210)
==17316== by 0x401250: main (main.c:189)
==17316== Address 0x40000 is not stack'd, malloc'd or (recently) free'd
==17316==
==17316==
==17316== Process terminating with default action of signal 11 (SIGSEGV)
==17316== Access not within mapped region at address 0x40000
==17316== at 0x4F4D91B: flatten_args (args.c:711)
==17316== by 0x4F4A427: MVM_args_checkarity (args.c:140)
==17316== by 0x4F54721: MVM_interp_run (interp.c:573)
==17316== by 0x5039D5C: MVM_vm_run_file (moar.c:210)
==17316== by 0x401250: main (main.c:189)
Is this something to do with P6Int having alternative storage representations?
sounds more like the number of arguments is a signed 16 bit int
somewhere, and overflows for calls with >= 2**15 arguments (which a long
list flattened into an argument list can cause).
Cheers,
Moritz
