Re: [perl #32676] testj hangs on string_102
Luke Palmer
> make testj hangs on string_102.pasm. Here's the gdb backtrace.
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
>
> % 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
>
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
Leopold Toetsch
> make testj hangs on string_102.pasm. Here's the gdb backtrace.
I can't reproduce that. Another Redhat or NPTL problem?
leo
Peter Sinnott
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
Leopold Toetsch
> Possibly unrelated.
Yes :)
> eval_4.pasm seems to be falling over on redhat as 3 when running
> with jit.
Yep. I've seen that too. I'm investigating.
Thanks,
leo
Leopold Toetsch
> eval_4.pasm seems to be falling over on redhat as 3 when running
> with jit.
Fixed.
leo