On Fri, Feb 06, 2009 at 01:44:52PM -0800, Andi Vajda wrote:
>
> It might be time to fiddle with vm args then.
> Have you tried -Xrs ? increasing the Java stack (-Xms) ?
> Maybe Java is garbage collecting something it shouldn't ?
It still crashes with
"vmargs="-Xms2G,-Xrs,-Xss2M"" (-Xms increases heap, -Xss increases
stack).
I've also tried -verbose:gc, and it doesn't seem to report any gc
activity either when running normally or when crashing. (I've
also tried -Xloggc:logFileName and -XX:+PrintGCDetails.) Swapping
in a different GC algorithm with -XX:UseSerialGC didn't seem to help.
(This is all with the code patched to return Py_None from initVM, so
it makes sense that we're not doing any allocation past startup, and
thus no GC. It is possible that I'm wrong, and that when the process
crashes, there's unflushed output indicating a GC.)
I've also been fiddling with the python driver. A version which asserts
that the just-inserted int is of type 'int' doesn't fault until we
check the entire array at the end: a version which checks the last 50
or soinserts so does fault, again at one of a small set of offsets.
Those offsets (0x14ff00, 0x12a9bc, 0x1a92bc) are near the series
of sizes at which Python reallocates a list (see Objects/listitem.c),
so it looks like perhaps the malloc arena is getting corrupted
in such a way as to not copy the last 8 bytes of data in a realloc'd
block?
I've tried compiling python --with-pydebug, and exporting MALLOC_CHECK_=3,
and either of these seems to perturb things enough that the bug no
longer manifests.
I've also tried modifying the output testjcc.c so it doesn't
contain the lines from INSTALL_TYPE(JObject,module) ... to
'__install__(module);', and it still seems to crash. At this point, the amount
of JCC
code running is really minimal ...
Aaron Lav (a...@pobox.com)
