Skip Menu |
Report information
Id: 128985
Status: resolved
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: ajs <ajs [at] ajs.com>
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [SEGV] in multi-level list reduction/evaluation
To: rakudobug [...] perl.org
Date: Thu, 18 Aug 2016 12:39:14 -0400
From: Aaron Sherman <ajs [...] ajs.com>
Download (untitled) / with headers
text/plain 353b
Was trying to list perfect numbers:

[12:37] <harmil_wk> m: say ^1000 .grep: -> $n {([+] ^$n .grep: -> $m {$m and $n %% $m}) == $n } # Perfect numbers?
[12:37] <+camelia> rakudo-moar 643c0f: OUTPUT«(signal SEGV)»

--
Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: ajs@ajs.com
Toolsmith, developer, gamer and life-long student.

Download (untitled) / with headers
text/plain 387b
Update: I found a way to make it not SEGV, but I'm not sure how to interpret the failure to fail: $ perl6 -e 'say (2..1000).grep: -> $n {([+] (1..($n-1)).grep: -> $m {$m and $n %% $m}) == $n }' (6 28 496) $ perl6 -e 'say (2..1000).grep: -> $n {([+] (1..^$n).grep: -> $m {$m and $n %% $m}) == $n }' Segmentation fault (core dumped) In theory, 1..^$n and 1..($n-1) should be the same...
Date: Thu, 18 Aug 2016 13:14:58 -0400
From: Brandon Allbery <allbery.b [...] gmail.com>
CC: bugs-bitbucket [...] rt.perl.org
To: perl6-compiler <perl6-compiler [...] perl.org>
Subject: Re: [perl #128985] [SEGV] in multi-level list reduction/evaluation
pyanfar Z$ rakudobrew exec perl6-valgrind-m -e 'say ^1000 .grep: -> $n {([+] ^$n .grep: -> $m {$m and $n %% $m}) == $n } # Perfect numbers?'    
================================================================================================
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.04.126.g.2.b.74.c.90 built on MoarVM version 2016.04,
running on ubuntu (14.04.2.LTS.Trusty.Tahr) / linux (3.13.0.37.generic)
------------------------------------------------------------------------------------------------
==9171== Memcheck, a memory error detector
==9171== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9171== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==9171== Command: /home/allbery/.rakudobrew/moar-nom/install/bin/moar --execname=/home/allbery/.rakudobrew/bin/../moar-nom/install/bin/perl6-valgrind-m --libpath=/home/allbery/.rakudobrew/moar-nom/install/share/nqp/lib --libpath=/home/allbery/.rakudobrew/moar-nom/install/share/perl6/lib --libpath=/home/allbery/.rakudobrew/moar-nom/install/share/perl6/runtime /home/allbery/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm -e say\ ^1000\ .grep:\ -\>\ $n\ {([+]\ ^$n\ .grep:\ -\>\ $m\ {$m\ and\ $n\ %%\ $m})\ ==\ $n\ }\ #\ Perfect\ numbers?
==9171== 
==9171== Invalid read of size 8
==9171==    at 0x4F9D4F5: MVM_interp_run (in /home/allbery/.rakudobrew/moar-nom/install/lib/libmoar.so)
==9171==    by 0x5052048: MVM_vm_run_file (in /home/allbery/.rakudobrew/moar-nom/install/lib/libmoar.so)
==9171==    by 0x401046: main (in /home/allbery/.rakudobrew/moar-nom/install/bin/moar)
==9171==  Address 0x48000000000009 is not stack'd, malloc'd or (recently) free'd
==9171== 
==9171== 
==9171== Process terminating with default action of signal 11 (SIGSEGV)
==9171==  General Protection Fault
==9171==    at 0x4F9D4F5: MVM_interp_run (in /home/allbery/.rakudobrew/moar-nom/install/lib/libmoar.so)
==9171==    by 0x5052048: MVM_vm_run_file (in /home/allbery/.rakudobrew/moar-nom/install/lib/libmoar.so)
==9171==    by 0x401046: main (in /home/allbery/.rakudobrew/moar-nom/install/bin/moar)
==9171== 
==9171== HEAP SUMMARY:
==9171==     in use at exit: 55,192,662 bytes in 215,556 blocks
==9171==   total heap usage: 242,533 allocs, 26,977 frees, 74,667,575 bytes allocated
==9171== 
==9171== LEAK SUMMARY:
==9171==    definitely lost: 8,974 bytes in 233 blocks
==9171==    indirectly lost: 21,784 bytes in 668 blocks
==9171==      possibly lost: 377,160 bytes in 6,738 blocks
==9171==    still reachable: 54,784,744 bytes in 207,917 blocks
==9171==         suppressed: 0 bytes in 0 blocks
==9171== Rerun with --leak-check=full to see details of leaked memory
==9171== 
==9171== For counts of detected and suppressed errors, rerun with: -v
==9171== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
zsh: exit 139   rakudobrew exec perl6-valgrind-m -e 

...I feel like I needed to specify some option(s) to get something more useful out of that; the addresses by themselves are less than useful. :/

On Thu, Aug 18, 2016 at 12:39 PM, Aaron Sherman <perl6-bugs-followup@perl.org> wrote:
Show quoted text
# New Ticket Created by  Aaron Sherman
# Please include the string:  [perl #128985]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=128985 >


Was trying to list perfect numbers:

[12:37] <harmil_wk> m: say ^1000 .grep: -> $n {([+] ^$n .grep: -> $m {$m
and $n %% $m}) == $n } # Perfect numbers?
[12:37] <+camelia> rakudo-moar 643c0f: OUTPUT«(signal SEGV)»

--
Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: ajs@ajs.com
Toolsmith, developer, gamer and life-long student.



--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 693b
On Thu, 18 Aug 2016 09:39:30 -0700, ajs wrote: Show quoted text
> Was trying to list perfect numbers: > > [12:37] <harmil_wk> m: say ^1000 .grep: -> $n {([+] ^$n .grep: -> $m {$m > and $n %% $m}) == $n } # Perfect numbers? > [12:37] <+camelia> rakudo-moar 643c0f: OUTPUT«(signal SEGV)» >
I can't reproduce this on HEAD, even with trying pretty hard to provoke it (regular GC collections and GC sanity checks turned on to make corruption bugs far more likely to show up, etc.) I've added a test in integration/weird-errors.t which will, if this is somehow still lingering, end up SEGVing also. I suspect in the months since this was filed, one of the many fixes that has gone in nailed it, though. /jnthn


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org