Steve Fink <[EMAIL PROTECTED]> wrote:
> Here's another obnoxious test case.
[ ... ]
> So, in case anyone is curious (hi leo!), attached is a 56KB (<9KB
> gzipped) imc file.
> It crashes on a memcpy inside compact_pool
Some remarks what I could find out:
- the damaged Buffer is in a pool of object_size 60
- Array/IntList (i.e. List) buffer_likes have that size
- valgrind reports a lot of unitialised values during DOD [1]
- some of these are in mark_context
- the context contains all kinds of aggregates
- current COW copying of stacks is AFAIK borken - both "copies" of
one COWed stack share the same Buffer header - I don't think the
the GC/compact_pool in resources.c does correctly deal with such
Buffers. COWed strings have distinct (String)Buffer headers.
It could be that e.g. lex Pads (which contain Arrays) aren't marked
properly (valgrind has indications for that):
==16728== Conditional jump or move depends on uninitialised value(s)
==16728== at 0x80C4BE0: pobject_lives (src/dod.c:91)
==16728== by 0x81C1B72: mark_stack (src/method_util.c:162)
==16728== by 0x81BD2B8: mark_context (src/sub.c:59)
And finally I have to admit, that the list code is too complex. I don't
think, that the error is directly caused by the list code (DOD/GC is
turned off during each allocation). But it seems to be overkill for the
average usage (mainly small Arrays).
It can deal with huge sparse arrays, tries to be space efficient, with
small arrays and is pretty fast. But all current array usage (except a
few tests) just put a few items into arrays and do not much mess around.
leo
[1] some of these are during stack trace, where valgrind doesn't see
what Parrot is doing - we can ignore these
