[perl #32092] Strange segfault when concatenating strings

[Matthias . Hoelzl @ ifi . lmu . de]

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

---
osname= linux
osvers= 2.4.21-14.elsmp
arch= i386-linux-thread-multi
cc= gcc 3.4.2 20041006 (Red Hat 3.4.2-5)
---
Flags:
category=core
severity=low
ack=no
---
Parrot segfaults when executing the appended function. If I shorten
the last definition of $S0 the program completes normally. When I
replace the last definition of $S0 with the "open - read - close"
sequence the program completes normally as well (the file
literal-list-1.text contains the last definition of $S0 as text).
Unfortunately I cannot extract a small test case, because everything
works all right as soon as I remove the calls to the application
specific functions. I can provide the full program, if this helps.

.sub test_compile_literal_list
$P0 = empty_list()
$P1 = cons($P0, $P0)
$S0 = ".local pmc tmp_0\n"
$S0 .= "tmp_0 = find_global \"%the-empty-list\"\n"
do_test_compile_literal_list($P0, $S0)

$S0 = ".local pmc tmp_1\n"
$S0 .= "tmp_1 = find_global \"%the-empty-list\"\n"
$S0 .= ".local pmc tmp_2\n"
$S0 .= "tmp_2 = find_global \"%the-empty-list\"\n"
$S0 .= ".local pmc tmp_0\n"
$S0 .= "tmp_0 = cons(tmp_1, tmp_2)\n"
do_test_compile_literal_list($P1, $S0)

$P0 = parrot_string_to_symbol("foobar")
$P1 = int_to_integer(1)
$P2 = create_pmc_list_2($P0, $P1)
#$P3 = open "literal-list-1.text", "<"
#$S0 = read $P3, 1024
#close $P3

$S0 = ""
$S0 = ".local string tmp_1\n"
$S0 .= "tmp_1 = \"foobar\"\n"
$S0 .= ".local pmc tmp_2\n"
$S0 .= "tmp_2 = parrot_string_to_symbol(tmp_1)\n"
$S0 .= ".local pmc tmp_4\n"
$S0 .= "tmp_4 = new Integer\n"
$S0 .= "tmp_4 = 1\n"
$S0 .= ".local pmc tmp_5\n"
$S0 .= "tmp_5 = find_global \"%the-empty-list\"\n"
$S0 .= ".local pmc tmp_3\n"
$S0 .= "tmp_3 = cons(tmp_4, tmp_5)\n"
$S0 .= ".local pmc tmp_0\n"
$S0 .= "tmp_0 = cons(tmp_2, tmp_3)\n"
print $S0
do_test_compile_literal_list($P2, $S0)
.end

---
Summary of my parrot 0.1.1 configuration:
configdate='Tue Oct 12 17:45:32 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

---
Environment:
HOME LANG LANGUAGE LD_LIBRARY_PATH LOGDIR PATH SHELL

[Leopold Toetsch]

Matthias . Hoelzl @ ifi . lmu . de <parrotbug...@parrotcode.org> wrote:

> Parrot segfaults when executing the appended function.

It's hard to tell, what's the problem. A debugger backtrace with
information about the relevant variables could help.

And: if the code runs with "parrot -G" then it's likely a GC bug. If the
segfault is happening earlier, when you run with --gc-debug and/or -t,
the it's very likely a GC bug.

Best is of course to extract a small piece of code that exposes the
error :)

leo

[Matthias Hölzl]

Leopold Toetsch wrote:

>Matthias . Hoelzl @ ifi . lmu . de <parrotbug...@parrotcode.org> wrote:
>
>
>>Parrot segfaults when executing the appended function.
>>
>>
>
>It's hard to tell, what's the problem. A debugger backtrace with
>information about the relevant variables could help.
>
>And: if the code runs with "parrot -G" then it's likely a GC bug. If the
>segfault is happening earlier, when you run with --gc-debug and/or -t,
>the it's very likely a GC bug.
>
>

The code runs fine with the "-G" flag and also with the "--gc-debug"
flag. It segfaults before finishing the first test when run with the
-t flag.
I have appended a backtrace with information about the relevant
variables. The backtrace seems to support your conclusion that the
segfault happens during garbage collection.

>Best is of course to extract a small piece of code that exposes the
>error :)
>
>

Sorry. I tried for some time to generate a small test case. But as soon
as I remove significant parts of the program, the segfault disappears... :-|

Matthias

[Leopold Toetsch]

Matthias Hölzl <Matthia...@ifi.lmu.de> wrote:
> I have appended a backtrace with information about the relevant
> variables. The backtrace seems to support your conclusion that the
> segfault happens during garbage collection.

Yep, thanks for the detailed output.

> 0x080e4169 in pobject_lives (interpreter=0x940a008, obj=0x11) at src/dod.c:198
> (gdb) print *sub_pmc
> _num_val = 1.5100122518759912e-263, _string_val = 0x95a58f0},
> ... flags = 524288,

(gdb) p /x 524288
$1 = 0x80000
(gdb) p /x b_PObj_on_free_list_FLAG
$3 = 0x80000

So definitely a DOD bug, the sub PMC is already freed.

Anyway, with the upcoming changes for register frames, it's likely that
this bug will be removed. Marking of live objects has to use the call
chain and not like now the active register frames directly.

leo