[perl #38800] Strange dump output from PGE (x86_64 related?)
Patrick R . Michaud
# Please include the string: [perl #38800]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38800 >
---
osname= linux
osvers= 2.6.12
arch= x86_64-linux-thread-multi
cc= cc
---
Flags:
category=core
severity=medium
ack=no
---
As mentioned on IRC, from time to time I get strange results in
my x86_64 platform that I don't run into under a 32-bit
environment. Leo asked me to file a ticket the next time I came
across the issue -- thus this message.
I'm running a fresh checkout of r12014. I wrote a simple test
program (t.pir attached) that uses "dumper.pir" to dump the
contents of one of PGE's internal variables. On my 64-bit
environment (SUSE 10 Professional Linux) I get very strange
output and the strings appear to have been corrupted. On
my 32-bit environment, the output is exactly as I would
expect it to be.
Here are the files I'm attaching to this message:
t.pir - test program
dump_32.txt - output from my 32-bit environment (expected output)
dump_64.txt - output from my 64-bit system
Notice in the dump_64.txt the way that the keys and
values of various hash entries appear to have been
corrupted.
Command used to produce output files:
./parrot t.pir >dump_xx.txt
I'm quite willing to admit that the problem may be in PGE
itself -- perhaps PGE is failing to initialize a register
or using a hash incorrectly and it's only being exposed under
x86_64. Any clues or suggestions on this bug will be
greatly appreciated, and if I can provide further details
or run the test with different options, I'll be happy to do
that as well.
Thanks,
Pm
---
Summary of my parrot 0.4.2 (r12014) configuration:
configdate='Fri Mar 24 21:37:23 2006'
Platform:
osname=linux, archname=x86_64-linux-thread-multi
jitcapable=0, jitarchname=nojit,
jitosname=linux, jitcpuarch=x86_64
execcapable=0
perl=/usr/bin/perl
Compiler:
cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC',
Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib64',
cc_ldflags='',
libs='-lm -ldl -lcrypt -lpthread -lrt'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib64 -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib64 -fPIC'
Types:
iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
ptrsize=8, ptr_alignment=1 byteorder=12345678,
nv=double, numvalsize=8, doublesize=8
---
Environment:
HOME LANG LANGUAGE LD_LIBRARY_PATH LOGDIR PATH SHELL
Leopold Toetsch
On Mar 25, 2006, at 5:11, Patrick R.Michaud (via RT) wrote:
> I'm running a fresh checkout of r12014. I wrote a simple test
> program (t.pir attached) that uses "dumper.pir" to dump the
> contents of one of PGE's internal variables. On my 64-bit
> environment (SUSE 10 Professional Linux) I get very strange
> output and the strings appear to have been corrupted. On
> my 32-bit environment, the output is exactly as I would
> expect it to be.
I've tried that with r12014 on an amd64/linux box. Dump is the same as
with 32bit. There must be more than just running it on 64-bit. You
could further test:
$ ./parrot -G t.pir >d # does it work with DOD/GC off?
$ ./parrot --gc-debug t.pir >d # is it worse?
$ ./parrot -D40 t.pir >d # fill I/N regs with garbage
You should also verify that you don't have some installed old copies of
parrot in your path.
leo
Leopold Toetsch
On Mar 25, 2006, at 5:11, Patrick R.Michaud (via RT) wrote:
> .sub main
> load_bytecode "PGE.pbc"
> load_bytecode "dumper.pir"
> load_bytecode "PGE/Dumper.pir"
>
> $P0 = find_global "PGE::P6Rule", "$optable"
> "_dumper"($P0)
>
> .end
Another note, I forgot to mention: above code doesn't work here.
$ ./parrot pmi.pir
error:imcc:syntax error, unexpected $end
in file
'/home/lt/svn/parrot/leo/runtime/parrot/library/Data/Dumper.pir' line
51
The line number is at the end of the file.
When I load_bytecode .pbc only, it runs.
*Hola* and it produces a corrupted dump on x86/linux (gcc 4.1,
--optimize), which vanishes when running with -G. Looks like a DOD/GC
bug now.
leo
Patrick R. Michaud
>
> On Mar 25, 2006, at 5:11, Patrick R.Michaud (via RT) wrote:
>
> >I'm running a fresh checkout of r12014. I wrote a simple test
> >program (t.pir attached) that uses "dumper.pir" to dump the
> >contents of one of PGE's internal variables. On my 64-bit
> >environment (SUSE 10 Professional Linux) I get very strange
> >output and the strings appear to have been corrupted. On
> >my 32-bit environment, the output is exactly as I would
> >expect it to be.
>
> I've tried that with r12014 on an amd64/linux box. Dump is the same as
> with 32bit. There must be more than just running it on 64-bit. You
> could further test:
>
> $ ./parrot -G t.pir >d # does it work with DOD/GC off?
> $ ./parrot --gc-debug t.pir >d # is it worse?
> $ ./parrot -D40 t.pir >d # fill I/N regs with garbage
With "-G" I get the correct output -- the other two fail the same
as when no options are present.
> You should also verify that you don't have some installed old copies of
> parrot in your path.
I never run "make install" on my system, so it's unlikely there
are old copies lying around. But just to be sure, I removed all
copies of parrot from my system and re-ran the tests and obtained
the same results.
I agree it looks like a GC bug, and not anything x86_64 specific.
It appears my x86_64 system is just good at flushing those out. :-)
Pm
Leopold Toetsch
On Mar 26, 2006, at 16:26, Patrick R. Michaud wrote:
> I agree it looks like a GC bug, and not anything x86_64 specific.
It was definitely a GC bug (COW copies of constant strings did move
string buffers).
Fixed r12062.
leo