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

Really really really odd precomp bug #3587

Closed
p6rt opened this issue Nov 21, 2014 · 10 comments
Closed

Really really really odd precomp bug #3587

p6rt opened this issue Nov 21, 2014 · 10 comments

Comments

@p6rt
Copy link

p6rt commented Nov 21, 2014

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

Searchable as RT123272$

@p6rt
Copy link
Author

p6rt commented Nov 21, 2014

From @hoelzro

Wow. Just, uh...wow. I had a hell of a time golfing down the code that demonstrated this bug; it's golfed down as much as it can be without fixing the bug, but there's still a substantial amount of code present, and there's no rhyme or reason to it. I can't even begin to describe what's going on here. As far as I can tell, it something to do with one or more of the following things working in concert.

  - Loading modules
  - Applying roles
  - Variables in modules that have initial state
  - String literals (I know, right?)

If I remove any instance of the above from the code, the bug no longer presents itself.

Attached is the golfed code; it's derived from github.com/colomon/ABC, which is how the bug was originally discovered. Install Rakudo-Moar and run 'make test' to see the bug in action. I'll test on Parrot/JVM later.

@p6rt
Copy link
Author

p6rt commented Nov 21, 2014

From @hoelzro

golfed-abc.tar.gz

@p6rt
Copy link
Author

p6rt commented Nov 21, 2014

From @hoelzro

Tried on JVM and Parrot; occurs on the JVM, and Parrot segfaults.

@p6rt
Copy link
Author

p6rt commented Nov 21, 2014

From @hoelzro

We should probably also try against the problem revisions in https://rt-archive.perl.org/perl6/Ticket/Display.html?id=122773 to see if the problem has been introduced since then.

@p6rt
Copy link
Author

p6rt commented Dec 15, 2015

From @hoelzro

On 2014-11-21 12​:29​:01, rob@​hoelz.ro wrote​:

We should probably also try against the problem revisions in
https://rt-archive.perl.org/perl6/Ticket/Display.html?id=122773 to see if the
problem has been introduced since then.

This is ok on Rakudo+MoarVM (as of Rakudo 59f7cb90f5d626f5e5bc0237e1ddff44e8c127eb); the JVM build is currently busted, so I can't on there.

@p6rt
Copy link
Author

p6rt commented Dec 19, 2015

From @skids

On Tue Dec 15 14​:11​:01 2015, rob@​hoelz.ro wrote​:

On 2014-11-21 12​:29​:01, rob@​hoelz.ro wrote​:

We should probably also try against the problem revisions in
https://rt-archive.perl.org/perl6/Ticket/Display.html?id=122773 to see if the
problem has been introduced since then.

This is ok on Rakudo+MoarVM (as of Rakudo
59f7cb90f5d626f5e5bc0237e1ddff44e8c127eb); the JVM build is currently
busted, so I can't on there.

Tests added. I back-engineered roast enough to verify that the tests
fail the same as the original example on commits < 59f7cb90. Actually
I found the tests failed on both the original tarball and roast
until the commit *after* 59f7cb9, dd13105, but maybe that was some
rebuild problem on my part.

Then I modernized the tests and used a new rakudo and they pass.

However, they only pass when run directly in roast with
t/spec/packages being a symlink to ./packages. Otherwise they
fall victim to the unrelated "run_alt" bug that's been floating
around. I was expecting that to go away under "make spectest"
because there, there is actually a t/spec/ directory already,
but they did not.

Maybe best to let them sit that way until run_alt is fixed,
as it does give another, probably reproduceable clue as to
what is causing that issue. Hopefully when that happens they
will happily start passing.

@p6rt
Copy link
Author

p6rt commented Dec 19, 2015

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

@p6rt
Copy link
Author

p6rt commented Dec 19, 2015

From @skids

On Fri Dec 18 23​:02​:47 2015, bri@​abrij.org wrote​:

On Tue Dec 15 14​:11​:01 2015, rob@​hoelz.ro wrote​:

On 2014-11-21 12​:29​:01, rob@​hoelz.ro wrote​:

We should probably also try against the problem revisions in
https://rt-archive.perl.org/perl6/Ticket/Display.html?id=122773 to see if the
problem has been introduced since then.

This is ok on Rakudo+MoarVM (as of Rakudo
59f7cb90f5d626f5e5bc0237e1ddff44e8c127eb); the JVM build is currently
busted, so I can't on there.

Tests added. I back-engineered roast enough to verify that the tests
fail the same as the original example on commits < 59f7cb90. Actually
I found the tests failed on both the original tarball and roast
until the commit *after* 59f7cb9, dd13105, but maybe that was some
rebuild problem on my part.

Then I modernized the tests and used a new rakudo and they pass.

However, they only pass when run directly in roast with
t/spec/packages being a symlink to ./packages. Otherwise they
fall victim to the unrelated "run_alt" bug that's been floating
around. I was expecting that to go away under "make spectest"
because there, there is actually a t/spec/ directory already,
but they did not.

Maybe best to let them sit that way until run_alt is fixed,
as it does give another, probably reproduceable clue as to
what is causing that issue. Hopefully when that happens they
will happily start passing.

Oh, sorry, roast commits 040bac7 and cee6b12, S10-packages/precompilation.rakudo.moar

@p6rt
Copy link
Author

p6rt commented Dec 23, 2015

From @skids

OK, either someone fixed the precomp run_alt, or it went along its way to bother
some other unsuspecting compunit. The tests are now passing, so I think
we are done here.

@p6rt
Copy link
Author

p6rt commented Dec 23, 2015

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

@p6rt p6rt closed this as completed Dec 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant