Front page | perl.perl6.internals |
Postings from September 2005
"Joshua Hoblitt via RT" <bugs-parrot-track@netlabs.develooper.com> wrote: >> [jhoblitt - Mon Sep 19 22:28:00 2005]: >> >> > [simon@netthink.co.uk - 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. JonathanThread Previous | Thread Next