Parrot Assembler via RT writes:

It looks like a really subtle, nasty problem.  If I add a noop anywhere
in the top section of code (before MAIN) it works.  It works even if I
change the filename from string_102.pasm to test.pasm!  It works if I
add a non-jit op (like print or find_type) right after MAIN.

Luke

# New Ticket Created by  Luke Palmer
# Please include the string:  [perl #32676]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32676 >

make testj hangs on string_102.pasm.  Here's the gdb backtrace.

% gdb parrot
GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run -j t/op/string_102.pasm
Starting program: /home/fibonaci/devel/parrot/parrot -j t/op/string_102.pasm
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.
[Thread debugging using libthread_db enabled]
[New Thread -150292160 (LWP 10828)]
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
[New Thread -159155280 (LWP 10831)]
[New Thread -169645136 (LWP 10832)]

Program received signal SIGINT, Interrupt.
[Switching to Thread -150292160 (LWP 10828)]
0x00880d34 in _int_malloc () from /lib/tls/libc.so.6
(gdb) bt
#0  0x00880d34 in _int_malloc () from /lib/tls/libc.so.6
#1  0x00881bbd in _int_memalign () from /lib/tls/libc.so.6
#2  0x00880467 in memalign () from /lib/tls/libc.so.6
#3  0x008826a6 in posix_memalign () from /lib/tls/libc.so.6
#4  0x080ab600 in mem_realloc_executable (old=0x9f13000, newsize=4720) at memexec.c:47
#5  0x080ad3d2 in build_asm (interpreter=0x9d21008, pc=0x9f1b1c0, code_start=0x9f1b1c0, code_end=0x9f1b56c, objfile=0x0)
    at src/jit.c:1402
#6  0x08160068 in init_jit (interpreter=0x9d21008, pc=0x9f1b1c0) at src/interpreter.c:461
#7  0x08160124 in runops_jit (interpreter=0x9d21008, pc=0x9f1b1c0) at src/interpreter.c:528
#8  0x08160495 in runops_int (interpreter=0x9d21008, offset=0) at src/interpreter.c:744
#9  0x081612d2 in runops (interpreter=0x9d21008, offs=0) at src/inter_run.c:81
#10 0x080d6308 in Parrot_runcode (interpreter=0x9d21008, argc=1, argv=0xfef6856c) at src/embed.c:762
#11 0x080d614f in Parrot_runcode (interpreter=0x9d21008, argc=1, argv=0xfef6856c) at src/embed.c:694
#12 0x0809b4fb in main (argc=1, argv=0xfef6856c) at imcc/main.c:581

% uname -a
Linux jabberwock 2.6.5-1.358custom #2 Mon Aug 16 05:15:44 MDT 2004 i686 athlon i386 GNU/Linux

% cat myconfig
Summary of my parrot 0.1.1 configuration:
  configdate='Mon Nov 29 03:39:43 2004'
  Platform:
    osname=linux, archname=i386-linux-thread-multi
    jitcapable=1, jitarchname=i386-linux,
    jitosname=LINUX, jitcpuarch=i386
    execcapable=1
    perl=/usr/bin/perl
  Compiler:
    cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING  -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
  Linker and Libraries:
    ld='gcc', ldflags=' -L/usr/local/lib',
    cc_ldflags='',
    libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
  Dynamic Linking:
    share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
    load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
  Types:
    iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
    ptrsize=4, ptr_alignment=1 byteorder=1234,
    nv=double, numvalsize=8, doublesize=8

I can't reproduce that. Another Redhat or NPTL problem?

leo

Possibly unrelated.

eval_4.pasm seems to be falling over on redhat as 3 when running
with jit. Its ok without jit and its fine with and without jit
on a different machine running debian linux on almost identical
hardware.

-sh-2.05b$ uname -a
Linux unresolvable 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686
i386 GNU/Linux
-sh-2.05b$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon)

-sh-2.05b$ /usr/bin/perl t/harness --gc-debug     t/pmc/eval.t
t/pmc/eval....ok                                                            
All tests successful.
Files=1, Tests=6,  0 wallclock secs ( 0.19 cusr +  0.06 csys =  0.25
CPU)
-sh-2.05b$ /usr/bin/perl t/harness --gc-debug  -j   t/pmc/eval.t

t/pmc/eval....NOK 4#     Failed test (t/pmc/eval.t at line 76)              
#          got: 'ok 1
# ok 2
# 8
# -1
# 6
# '
#     expected: 'ok 1
# ok 2
# 8
# -1
# 6
# 11
# '
# '(cd . && ./parrot -j --gc-debug "/tmp/parrot/t/pmc/eval_4.pasm")'
# failed with exit code 139
t/pmc/eval....ok 6/6# Looks like you failed 1 tests of 6.                    
t/pmc/eval....dubious                                                        
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 4
Failed 1/6 tests, 83.33% okay
Failed Test  Stat Wstat Total Fail  Failed  List of
Failed
--------------------------------------------------------------------------- ----
t/pmc/eval.t    1   256     6    1  16.67%  4
Failed 1/1 test scripts, 0.00% okay. 1/6 subtests
failed, 83.33% okay.

#0  0x08240b08 in clear_fixup (interpreter=0x83585c0, self=0x8391460) at
classes/sub.c:72
72          for (i = 0; i < ft->fixup_count; i++) {
(gdb) backtrace
#0  0x08240b08 in clear_fixup (interpreter=0x83585c0, self=0x8391460) at
classes/sub.c:72
#1  0x08240c4f in Parrot_Sub_destroy (interpreter=0x83585c0,
pmc=0x8391460) at classes/sub.c:127
#2  0x080dc765 in Parrot_dod_sweep (interpreter=0x83585c0,
pool=0x8378cf0) at src/dod.c:797
#3  0x080dccd9 in Parrot_dod_ms_run (interpreter=0x83585c0, flags=1) at
src/dod.c:1180
#4  0x080dcdda in Parrot_do_dod_run (interpreter=0x83585c0, flags=1) at
src/dod.c:1226
#5  0x080a5775 in string_equal (interpreter=0x83585c0, s1=0x837a61c,
s2=0x8382248) at src/string.c:1839
#6  0x0857d1e8 in ?? ()
#7  0x083585c0 in ?? ()
#8  0x0837a61c in ?? ()
#9  0x08382248 in ?? ()
#10 0x083585c0 in ?? ()
#11 0xb745f67c in optopt () from /lib/tls/libc.so.6
#12 0xbfffbba4 in ?? ()
#13 0xb7461d98 in __DTOR_END__ () from /lib/tls/libc.so.6
#14 0xbfffba38 in ?? ()
#15 0x0815f8f8 in runops_jit (interpreter=0x83585c0, pc=0x8551530) at
src/interpreter.c:529
Previous frame identical to this frame (corrupt stack?)

--
Our goal is to proactively pursue business infrastructures in order that
we may efficiently create interdependent meta-services to stay competitive
in tomorrow's world

Yes :)

Yep. I've seen that too. I'm investigating.

Thanks,
leo

Fixed.

leo