Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reduce meta-operator fails with 'max' on list larger than 2**15 with MoarVM #3743

Open
p6rt opened this issue Mar 18, 2015 · 5 comments
Open
Labels

Comments

@p6rt
Copy link

p6rt commented Mar 18, 2015

Migrated from rt.perl.org#124108 (status was 'open')

Searchable as RT124108$

@p6rt
Copy link
Author

p6rt commented Mar 18, 2015

From dhoekman@gmail.com

In perl6 (version=2015.01-147-g949b809) under MoarVM
(version=2015.01-69-g5bbfd1a)​:

perl6-j -e 'say [max] 1..2**15'
32768
perl6-m -e 'say [max] 1..2**15'
32768
perl6-j -e 'say [max] 1..(1+2**15)'
32769
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

[min] fails as well, but [minmax] works

@p6rt
Copy link
Author

p6rt commented Mar 19, 2015

From @nwc10

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?

If so, it implies that some more tests would be useful for values around the
switchover points.

(To be robust I'd suggest testing all ranges ±2 around values 256**n for
n 0 to 9)

Nicholas Clark

@p6rt
Copy link
Author

p6rt commented Mar 19, 2015

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

@p6rt
Copy link
Author

p6rt commented Mar 19, 2015

From @moritz

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

@p6rt
Copy link
Author

p6rt commented May 2, 2016

From @smls

New behavior on current Rakudo​:

  ➜ perl6-m -e 'say [max] 1..(1+2**15)'
  32769

  ➜ perl6-m -e 'say [max] 1..(1+2**16)'
  Too many arguments in flattening array.
  in block <unit> at -e line 1

I.e. it gives a useful error message now, instead of an LTA one. So maybe this RT can be closed?

On the other hand, it could be argued that the [ ] metaop should be smart enough to handle a single Range (or other lazy Iterable) argument without forcing it to eagerly flatten.

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant