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

Too many repetitions with xx operator causes out of memory; should it work lazily? #4523

Closed
p6rt opened this issue Sep 7, 2015 · 9 comments

Comments

@p6rt
Copy link

p6rt commented Sep 7, 2015

Migrated from rt.perl.org#126014 (status was 'resolved')

Searchable as RT126014$

@p6rt
Copy link
Author

p6rt commented Sep 7, 2015

From @AlexDaniel

$ perl6 -e '"x" xx 9999999999'
Segmentation fault

It seems like on 64-bit systems you get �«Memory allocation failed; could
not allocate 79999999992 bytes� error instead of segfault.

@p6rt
Copy link
Author

p6rt commented Apr 30, 2016

From @AlexDaniel

OK, I said that it only segfaults on 32-bit systems, but I was wrong.

Code​:
42 xx (2 ** 62)

Result​:
Segmentation fault

And of course it is also possible to replicate it on camelia​: http://irclog.perlgeek.de/perl6/2016-04-30#i_12413634

So I'll change the title.

@p6rt
Copy link
Author

p6rt commented Oct 8, 2016

From @MasterDuke17

On Sat Apr 30 03​:42​:00 2016, alex.jakimenko@​gmail.com wrote​:

OK, I said that it only segfaults on 32-bit systems, but I was wrong.

Code​:
42 xx (2 ** 62)

Result​:
Segmentation fault

And of course it is also possible to replicate it on camelia​:
http://irclog.perlgeek.de/perl6/2016-04-30#i_12413634

So I'll change the title.

================================================================================================
This is Rakudo Perl 6 running in valgrind, a tool for debugging and profiling programs.
Running a program in valgrind usually takes *a lot* more time than running it directly,
so please be patient.
This Rakudo version is 2016.09.144.g.2285.d.35 built on MoarVM version 2016.09.30.g.9.a.2.ab.14,
running on arch (4.7.3.1.arch) / linux (4.7.6.1.ARCH)


==30606== Memcheck, a memory error detector
==30606== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==30606== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==30606== Command​: /home/dan/Source/perl6/install/bin/moar --full-cleanup --execname=./install/bin/perl6-valgrind-m --libpath=/home/dan/Source/perl6/install/share/nqp/lib --libpath=/home/dan/Source/perl6/install/share/perl6/lib --libpath=/home/dan/Source/perl6/install/share/perl6/runtime /home/dan/Source/perl6/install/share/perl6/runtime/perl6.moarvm -e 42\ xx\ (2\ **\ 62)
==30606==
WARNINGS for -e​:
Useless use of constant integer 42 in sink context (line 1)
==30606== Invalid write of size 8
==30606== at 0x4FE4048​: zero_slots (MVMArray.c​:235)
==30606== by 0x4FE4048​: set_size_internal (MVMArray.c​:338)
==30606== by 0x4FE4048​: set_elems (MVMArray.c​:431)
==30606== by 0x4FA1AEE​: MVM_interp_run (interp.c​:2263)
==30606== by 0x505D128​: MVM_vm_run_file (moar.c​:304)
==30606== by 0x400ED3​: main (main.c​:191)
==30606== Address 0xb6e88b0 is 0 bytes after a block of size 0 alloc'd
==30606== at 0x4C29BBE​: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30606== by 0x4FE3EFF​: MVM_malloc (alloc.h​:2)
==30606== by 0x4FE3EFF​: set_size_internal (MVMArray.c​:334)
==30606== by 0x4FE3EFF​: set_elems (MVMArray.c​:431)
==30606== by 0x4FA1AEE​: MVM_interp_run (interp.c​:2263)
==30606== by 0x505D128​: MVM_vm_run_file (moar.c​:304)
==30606== by 0x400ED3​: main (main.c​:191)
==30606==
==30606==
==30606== Process terminating with default action of signal 11 (SIGSEGV)​: dumping core
==30606== Bad permissions for mapped region at address 0xB7D2000
==30606== at 0x4FE4048​: zero_slots (MVMArray.c​:235)
==30606== by 0x4FE4048​: set_size_internal (MVMArray.c​:338)
==30606== by 0x4FE4048​: set_elems (MVMArray.c​:431)
==30606== by 0x4FA1AEE​: MVM_interp_run (interp.c​:2263)
==30606== by 0x505D128​: MVM_vm_run_file (moar.c​:304)
==30606== by 0x400ED3​: main (main.c​:191)
==30606==
==30606== HEAP SUMMARY​:
==30606== in use at exit​: 47,479,952 bytes in 198,205 blocks
==30606== total heap usage​: 210,802 allocs, 12,597 frees, 55,693,684 bytes allocated
==30606==
==30606== LEAK SUMMARY​:
==30606== definitely lost​: 8,766 bytes in 181 blocks
==30606== indirectly lost​: 22,368 bytes in 668 blocks
==30606== possibly lost​: 392,896 bytes in 7,019 blocks
==30606== still reachable​: 47,055,922 bytes in 190,337 blocks
==30606== suppressed​: 0 bytes in 0 blocks
==30606== Rerun with --leak-check=full to see details of leaked memory
==30606==
==30606== For counts of detected and suppressed errors, rerun with​: -v
==30606== ERROR SUMMARY​: 119530 errors from 1 contexts (suppressed​: 0 from 0)

@p6rt
Copy link
Author

p6rt commented Oct 8, 2016

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

@p6rt
Copy link
Author

p6rt commented Feb 22, 2017

From @jnthn

On Sat, 30 Apr 2016 03​:42​:00 -0700, alex.jakimenko@​gmail.com wrote​:

OK, I said that it only segfaults on 32-bit systems, but I was wrong.

Code​:
42 xx (2 ** 62)

Result​:
Segmentation fault

This is patched in MoarVM HEAD just now and no longer SEGVs (reports the array is too long to allocate). So, no longer a SEGV bug.

However, I'm a bit surprised that xx does not work lazily, and actually makes such a huge array up-front. Not sure if we want to re-purpose the ticket for that; I'll remove the SEGV from the title, however, since that is resolved.

@p6rt
Copy link
Author

p6rt commented Feb 22, 2017

From @lizmat

On 22 Feb 2017, at 12​:41, jnthn@​jnthn.net via RT <perl6-bugs-followup@​perl.org> wrote​:
On Sat, 30 Apr 2016 03​:42​:00 -0700, alex.jakimenko@​gmail.com wrote​:

OK, I said that it only segfaults on 32-bit systems, but I was wrong.

Code​:
42 xx (2 ** 62)

Result​:
Segmentation fault

This is patched in MoarVM HEAD just now and no longer SEGVs (reports the array is too long to allocate). So, no longer a SEGV bug.

However, I'm a bit surprised that xx does not work lazily, and actually makes such a huge array up-front. Not sure if we want to re-purpose the ticket for that; I'll remove the SEGV from the title, however, since that is resolved.

Ah, yes, I remember we discussed this. Iâ��ll make it a Seq, although the question then becomes​: should it be lazy or not? If it is not lazy, we would just be postponing the exception in some cases.

Liz

@p6rt
Copy link
Author

p6rt commented Mar 10, 2018

From @dogbert17

On Wed, 22 Feb 2017 03​:59​:05 -0800, elizabeth wrote​:

On 22 Feb 2017, at 12​:41, jnthn@​jnthn.net via RT <perl6-bugs-
followup@​perl.org> wrote​:
On Sat, 30 Apr 2016 03​:42​:00 -0700, alex.jakimenko@​gmail.com wrote​:

OK, I said that it only segfaults on 32-bit systems, but I was
wrong.

Code​:
42 xx (2 ** 62)

Result​:
Segmentation fault

This is patched in MoarVM HEAD just now and no longer SEGVs (reports
the array is too long to allocate). So, no longer a SEGV bug.

However, I'm a bit surprised that xx does not work lazily, and
actually makes such a huge array up-front. Not sure if we want to re-
purpose the ticket for that; I'll remove the SEGV from the title,
however, since that is resolved.

Ah, yes, I remember we discussed this. I�ll make it a Seq, although
the question then becomes​: should it be lazy or not? If it is not
lazy, we would just be postponing the exception in some cases.

Liz

Fixed with commit rakudo/rakudo@1eb7b1f

@p6rt
Copy link
Author

p6rt commented Apr 8, 2018

From @AlexDaniel

Tests in Raku/roast@b320464

Closing

On 2018-03-10 11​:25​:06, jan-olof.hendig@​bredband.net wrote​:

On Wed, 22 Feb 2017 03​:59​:05 -0800, elizabeth wrote​:

On 22 Feb 2017, at 12​:41, jnthn@​jnthn.net via RT <perl6-bugs-
followup@​perl.org> wrote​:
On Sat, 30 Apr 2016 03​:42​:00 -0700, alex.jakimenko@​gmail.com wrote​:

OK, I said that it only segfaults on 32-bit systems, but I was
wrong.

Code​:
42 xx (2 ** 62)

Result​:
Segmentation fault

This is patched in MoarVM HEAD just now and no longer SEGVs
(reports
the array is too long to allocate). So, no longer a SEGV bug.

However, I'm a bit surprised that xx does not work lazily, and
actually makes such a huge array up-front. Not sure if we want to
re-
purpose the ticket for that; I'll remove the SEGV from the title,
however, since that is resolved.

Ah, yes, I remember we discussed this. I’ll make it a Seq, although
the question then becomes​: should it be lazy or not? If it is not
lazy, we would just be postponing the exception in some cases.

Liz

Fixed with commit
rakudo/rakudo@1eb7b1f

@p6rt
Copy link
Author

p6rt commented Apr 8, 2018

@AlexDaniel - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Apr 8, 2018
@p6rt p6rt added the testneeded label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant