bug detecting circular dependencies

[p6rt]

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

Searchable as RT126688$

[p6rt]

From @MARTIMM

Circular dependencies on modules are not detected anymore.

Golfed code;

File 1

  use v6;
  use Circ1;

File 2 (Circ1.pm6)

  use v6;
  use Circ2;

File 3 (Circ2.pm6)

  use v6;
  use Circ1;

This will bring the computer to its knees!

When installing the new version it seems that the bug is there for a
month or longer​: ...
Perl6 version 2015.10-206-gca7ed86 built on MoarVM version
2015.10-56-g9fd3005
Perl6 version 2015.11-5-g08a804c built on MoarVM version 2015.11

Greetings,
Marcel Timmerman

[p6rt]

From @autarch

I can confirm that this is still happening as of today's rakudo. It seems like an important bug to fix, but maybe more importantly, how are we supposed to handle circular deps? Consider a pair of classes, Tree and Node, which both need to refer to each other.

Tree.pm6

---

unit class Tree;

use Node;

has Node $top;

---

Node.pm6

---

unit class Node;

use Tree;

has Tree $tree;

---

Given that I have to use a module in order to refer to its type, this seems like a problem that will occur _way_ more often in Perl 6 than in Perl 5.

[p6rt]

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

[p6rt]

From @MARTIMM

On 12/31/2015 06​:58 AM, Dave Rolsky via RT wrote​:

I can confirm that this is still happening as of today's rakudo. It seems like an important bug to fix, but maybe more importantly, how are we supposed to handle circular deps? Consider a pair of classes, Tree and Node, which both need to refer to each other.

Tree.pm6
--------

unit class Tree;

use Node;

has Node $top;

--------

Node.pm6
--------

unit class Node;

use Tree;

has Tree $tree;
--------

Given that I have to use a module in order to refer to its type, this seems like a problem that will occur _way_ more often in Perl 6 than in Perl 5.

Often you can cope by not typing them in both modules . Then e.g. the
node create method in the Tree module creates the Node object which
receives the Tree object via the BUILD method. The Node module then does
not have to import the tree module because all information is included
in the Tree object just received. So the 'use Tree;' in Node.pm is not
needed.

[p6rt]

From @Skarsnik

Using https://gist.github.com/Skarsnik/df17adee07c18fa52c00 as a test

Perl6 just go on forever. Tested with a recent Rakudo

skarsnik@​testperl6​:~/devel/tmp$ ../rakudo/install/bin/perl6 --version
This is Rakudo version 2015.12-198-g997d7d1 built on MoarVM version 2015.12-29-g8079ca5
implementing Perl 6.c.

[p6rt]

From @MARTIMM

On 01/12/2016 02​:26 PM, Sylvain Colinet (via RT) wrote​:

# New Ticket Created by Sylvain Colinet
# Please include the string​: [perl #​127247]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=127247 >

Using https://gist.github.com/Skarsnik/df17adee07c18fa52c00 as a test

Perl6 just go on forever. Tested with a recent Rakudo

skarsnik@​testperl6​:~/devel/tmp$ ../rakudo/install/bin/perl6 --version
This is Rakudo version 2015.12-198-g997d7d1 built on MoarVM version 2015.12-29-g8079ca5
implementing Perl 6.c.
See also bug 126688 bug detecting circular dependencies

[p6rt]

From @MadcapJake

1. have a `lib` directory with a circularly dependent files (such as these
<https://gist.github.com/MadcapJake/9b8d36c0cef1b7062b7c>)
2. run «perl6 -Ilib -c A.pm6» where `lib` is the lib from previous step and
`A.pm6` is the path to A.pm6
3. watch as your machine dies in a horrible inferno

To elaborate on said inferno, my machine locks up in less than a minute.
It starts with some frozen mouse movements and then gets slower and slower
as the minute wears on.

So I restart and tried again this time with a process monitor open to see
if I can notice which process is causing this. I found that there were
hundreds of `moar` processes and I tried selecting them all and killing and
it would just create more and more. I could have a reasonably working
desktop if I killed all moar processes every second.

[p6rt]

From @masak

<RabidGravy> I like to (possibly superstitiously) have a test file with just use-ok in it to catch any weird dependency issues
<masak> RabidGravy​: all I can say is, I've never used `use-ok`, not even in a separate file, and I don't feel that *not* getting the `use` error separately has in any way detracted from the testing experience.
<masak> in fact, the usual reason I get `use` errors in the first place is because I forgot to `export PERL6LIB=lib` :)
<masak> and that's easily fixed, no matter whether I have a separate test file with `use-ok` or not
<RabidGravy> I think, for me, it goes back to testing very large programs using moose where it was easy to miss circular dependencies at a distance (e.g. where A uses B uses C uses D uses A) and things would stop loading under certain circumstances
<masak> RabidGravy​: I was going to say that "we don't allow that kind of circular dependencies to happen in Perl 6"
<masak> RabidGravy​: ...but then I tried it, and it puts Rakudo in an infinite loop :(
<masak> just A.pm containing `use B;` and vice versa triggers it
* masak submits rakudobug
<masak> if nothing else, it's a crappy default
<moritz> masak​: there's a rakudobug open already
<masak> oh, ok
* masak stands down
<masak> if I find it, I can add this discussion
<masak> ah, https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126688

[p6rt]

From @MARTIMM

There should be already several bug reports mentioning this. I and someone
else have reported this. I forgot the bug numbers though, I am on a
vacation and therefore not able to find the bug number, sorry

Marcel Timmerman

On March 27, 2016 6​:47​:08 PM Carl Mäsak via RT
<perl6-bugs-followup@​perl.org> wrote​:

<RabidGravy> I like to (possibly superstitiously) have a test file with
just use-ok in it to catch any weird dependency issues
<masak> RabidGravy​: all I can say is, I've never used `use-ok`, not even in
a separate file, and I don't feel that *not* getting the `use` error
separately has in any way detracted from the testing experience.
<masak> in fact, the usual reason I get `use` errors in the first place is
because I forgot to `export PERL6LIB=lib` :)
<masak> and that's easily fixed, no matter whether I have a separate test
file with `use-ok` or not
<RabidGravy> I think, for me, it goes back to testing very large programs
using moose where it was easy to miss circular dependencies at a distance
(e.g. where A uses B uses C uses D uses A) and things would stop loading
under certain circumstances
<masak> RabidGravy​: I was going to say that "we don't allow that kind of
circular dependencies to happen in Perl 6"
<masak> RabidGravy​: ...but then I tried it, and it puts Rakudo in an
infinite loop :(
<masak> just A.pm containing `use B;` and vice versa triggers it
* masak submits rakudobug
<masak> if nothing else, it's a crappy default
<moritz> masak​: there's a rakudobug open already
<masak> oh, ok
* masak stands down
<masak> if I find it, I can add this discussion
<masak> ah, https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126688

[p6rt]

From @smls

When two modules `use` each other, Rakudo does not throw a compile-time error as it should.
Instead, it just hangs and keeps eating more and more RAM until the kernel kills the program.

Minimalist test case to reproduce the problem​:

  $ echo "use B;" > A.pm
  $ echo "use A;" > B.pm
  $ perl6 -I. -e 'use A;'

Insight from IRC discussion​:

  psch​: we did have circular module loading detection at some point...
  probably got clobbered with all the CUR work though :/

  lizmat​: before, the detection lived in the nqp code, if I recall
  now, it is the responsibility of the CUR to detect circularities
  a start would be writing a test :-)

---

This is Rakudo version 2016.05-26-g7500ea2 built on MoarVM version 2016.05
implementing Perl 6.c.

[p6rt]

From @zoffixznet

This is fixed per https://irclog.perlgeek.de/perl6/2017-09-05#i_15118699

Marking as TESTNEEDED

[p6rt]

From @zoffixznet

Tests added Raku/roast@5685050756

[p6rt]

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