"Joshua Hoblitt via RT" <[EMAIL PROTECTED]> wrote:
[jhoblitt - Mon Sep 19 22:28:00 2005]:
> [EMAIL PROTECTED] - Sun Sep 22 07:13:56 2002]:
>
> The point of having a validifiable magic number at the start
> of a bytecode file is to avoid this sort of thing:
>
> % ../../parrot -j mops.pasm
> PackFile_unpack: Unimplemented wordsize transform.
> File has wordsize: 35 (native is 4)
> Parrot VM: Can't unpack packfile mops.pasm.
>
> If you're going to check the magic after the wordsize and bytecode, you
> might as well get rid of it altogether.
>
The only way we can *really* fix this is by not storing the magic number in
native endian form. At the moment we have to read the byteorder before the
magic number so we can transform it into native form.
Of course, there's nothing to prevent us putting in a "hack" that says "is
this magic number OK in any of the byte orderings we support".
This is a design decision - Chip (or leo), which road should we go down?
Change the packfile format, or code around the current way we do it?
The issue seems to be related to the jit core being in use. I can't
recreate it on amd64 (no jit)
I can't see any way it could be something to do with the JIT core, or any
runcore. We haven't even entered one at the point the above error is given.
but I can cause a segfault from random input on x86.
--
$ ./parrot -j docs/running.pod
Segmentation fault
--
This is a Bad Thing and needs fixing. I'll see what I can find - I don't
even see a segfault or any other error mesage under Win32, which is at least
as bad.
Jonathan has volunteered to look into this. Thanks.
I'll do what I can.
Jonathan
