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

in multi-level list reduction/evaluation #5591

Closed
p6rt opened this issue Aug 18, 2016 · 6 comments
Closed

in multi-level list reduction/evaluation #5591

p6rt opened this issue Aug 18, 2016 · 6 comments
Labels

Comments

@p6rt
Copy link

@p6rt p6rt commented Aug 18, 2016

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

Searchable as RT128985$

@p6rt
Copy link
Author

@p6rt p6rt commented Aug 18, 2016

From @ajs

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.

@p6rt
Copy link
Author

@p6rt p6rt commented Aug 18, 2016

From @ajs

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...

@p6rt
Copy link
Author

@p6rt p6rt commented Aug 18, 2016

From @geekosaur

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​:

# 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-archive.perl.org/perl6/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

@p6rt
Copy link
Author

@p6rt p6rt commented Aug 18, 2016

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

@p6rt
Copy link
Author

@p6rt p6rt commented Dec 7, 2016

From @jnthn

On Thu, 18 Aug 2016 09​:39​:30 -0700, ajs wrote​:

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

@p6rt p6rt closed this Dec 7, 2016
@p6rt
Copy link
Author

@p6rt p6rt commented Dec 7, 2016

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

@p6rt p6rt added the SEGV 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant