Ticket #1812 (closed bug: invalid)

Opened 11 years ago

Last modified 11 years ago

Less Than Awesome error message when new Rakudo tries to run on old Parrot

Reported by: masak Owned by: plobsing
Priority: normal Milestone:
Component: core Version: 2.8.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description (last modified by masak) (diff)

<masak> "PackFile header failed during unpack"
<masak> I just want to emphasize how much that error message,
meaning "wrong Parrot for this Rakudo", sucks.
<jnthn> masak: That probably needs to be a Parrot chnage, since it's
before Rakudo gets chance to take control and have its way with things.
<jnthn> masak: But I agree it's not clear at all to 99% of people.
<masak> I'll see about submitting a parrotbug.

Change History

follow-up: ↓ 3   Changed 11 years ago by plobsing

  • status changed from new to assigned
  • owner set to plobsing

If a newer parrot cannot read a PBC generated by an older parrot, there should be a PBC_COMPAT difference, which can and should be identified and raise a better error.

Either there was a change that didn't get an appropriate bump, or we're not looking at the PBC_COMPAT number early enough in the pbc decoder.

Can you submit the revs of both the compile-time and run-time parrots? If the old parrot is no longer available (and you don't remember the rev), the first couple hundred bytes of the PBC hexdumped might also be useable.

  Changed 11 years ago by masak

  • description modified (diff)

in reply to: ↑ 1 ; follow-up: ↓ 4   Changed 11 years ago by masak

Replying to plobsing:

If a newer parrot cannot read a PBC generated by an older parrot, there should be a PBC_COMPAT difference, which can and should be identified and raise a better error. Either there was a change that didn't get an appropriate bump, or we're not looking at the PBC_COMPAT number early enough in the pbc decoder. Can you submit the revs of both the compile-time and run-time parrots? If the old parrot is no longer available (and you don't remember the rev), the first couple hundred bytes of the PBC hexdumped might also be useable.

Since I update both Parrot and Rakudo continuously as part of my use of them, I'm not sure I'll be able to retrieve the exact versions I had when doing the update.

However, I tried just now to update Parrot to r49516 (and build it) while keeping Rakudo fixed at 2010.09-37-g9702438. Running (the old, still installed) Rakudo, I now get the error message

$ perl6 -e 'say "OH HAI"'
OpLib must be initialized with an oplib name

which also isn't very clear.

I'll see if I can reproduce the circumstances that led to the original error.

in reply to: ↑ 3   Changed 11 years ago by plobsing

Replying to masak:

Replying to plobsing:

Can you submit the revs of both the compile-time and run-time parrots? If the old parrot is no longer available (and you don't remember the rev), the first couple hundred bytes of the PBC hexdumped might also be useable.

However, I tried just now to update Parrot to r49516 (and build it) while keeping Rakudo fixed at 2010.09-37-g9702438. Running (the old, still installed) Rakudo, I now get the error message

What revision is the parrot that was used to compile the old rakudo? Knowing this is essential to understanding the problem. './perl6 -v' should be able to tell you this.

$ perl6 -e 'say "OH HAI"'
OpLib must be initialized with an oplib name

which also isn't very clear.

What is most likely happening here is that PMCs have become renumbered, but PBC_COMPAT has not been bumped. Trying to read old bytecode will attempt create and use objects which are not of the expected types. Confusion ensues.

I'll see if I can reproduce the circumstances that led to the original error.

Please do, but rembember to provide:

  • The revision of parrot used to compile rakudo
  • The revision of parrot used to run rakudo
  • The revision of rakudo

follow-up: ↓ 6   Changed 11 years ago by jkeenan

  • component changed from none to core

masak, plobsing:

Can you provide an update on the status of the problems discussed in this ticket?

Thank you very much.

kid51

in reply to: ↑ 5   Changed 11 years ago by plobsing

  • status changed from assigned to closed
  • resolution set to invalid

Replying to jkeenan:

All that can be said is that at some time in the past, there may have been a situation in which Parrot did not properly identify bytecode originating from an incompatible Parrot. This situation may or may not persist in the current implementation.

Closing as invalid, since the information provided is insufficient to constitute a valid bug.

Note: See TracTickets for help on using tickets.