Hi,
The following code crashes parrot if run with -t (trace).
It seems to be due to an unused .param, see line marked with XXX.
jens
> Hi,
> The following code crashes parrot if run with -t (trace).
> It seems to be due to an unused .param, see line marked with XXX.
The unused param doesn't harm. The problem is memory corruption very
likely due to the PIO_printf code inside trace.c (or string code called
from that).
The extra line just lets more of these functions be called.
$ parrot -tG crash.imc
runs fine.
> jens
leo
> The following code crashes parrot if run with -t (trace).
Some more notes:
- it happens with or w/o ARENA_DOD_FLAGS
- it happens with the copying GC or with --gc=libc
- it does not happen with DOD/GC disabled
- I did not find any breakage in e.g. examples/benchmarks/*.pasm
- it could be related to objects - currently only your crash.imc and
oo1.pasm are failing
The segfault is normally related to the string_header pool:
at src/smallobject.c:270
270 pool->free_list = *(void **)ptr;
The corrupted free_list looks like these:
(gdb) p ptr
$8 = (void *) 0x32000000
(gdb) p ptr
$9 = (void *) 0x33000000
(gdb) p ptr
$11 = (void *) 0x3d303100
Could be some numbers from the trace.
leo
> The following code crashes parrot if run with -t (trace).
Fixed.
That was not an easy one. A slightly wrong implementation (braino
courtesy of leo) did reset interpreter->lo_var_ptr (the stack limit),
when reentering the run loop, e.g. in object's __init calls.
This lead to memory corruption if a DOD or GC was triggered inside the
method call. During tracing, a lot of string handling is done, which
sooner or later always exposed the bug.
> jens
leo
- It's been happening for quite a while.
There have been a number of times when I haven't been able to run
with -t with code that uses ncurses.pasm or postgres.pasm. (Though
sometimes it works as well, which is darned annoying) Never took the
tiem to track it down, though.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
> - It's been happening for quite a while.
This one is fixed already. I've here two more fixed - one (the final) is
still sitting around.
leo
Yeah, I saw that. I do apologize for the recent flood of e-mail--what
I wrote is actually relatively old (day or so) but got caught in my
queue for some reason. I unblocked it and things went flooding out,
though I don't quite know why.