[pypy-dev] unable to translate with current head of default
wlavrijsen at lbl.gov
wlavrijsen at lbl.gov
Tue May 31 20:46:35 CEST 2011
Hi,
[replying to myself]
> okay, something has been fixed over the past couple of days: the readline
> now works! :) I'll move up to that then.
too fast ... it sometimes works, and when it doesn't, it sometimes does under
gdb or valgrind. Sometimes if I start a new shell, it works, then stops working
again for another. (Although the downloaded pypy-c's have never crashed, mind.)
This would make me think that there's an uninitialized variable somewhere. Is it
possible to create such a thing with a buggy RPython construct?
That said, the results with gdb or valgrind are always the same, when they do
show the crash:
Valgrind:
==16631== Process terminating with default action of signal 11 (SIGSEGV)
==16631== Access not within mapped region at address 0x4
==16631== at 0x8AADB0C: pypy_g_OptHeap_emitting_operation (in /home/wlav/pypydev/pypy/pypy/translator/goal/pypy-c)
gdb:
0x8aadb0c <pypy_g_OptHeap_emitting_operation+604>: cmp 0x4(%edi),%eax
0x8aadb0f <pypy_g_OptHeap_emitting_operation+607>: jl 0x8aadb37 <pypy_g_OptHeap_emitting_operation+647>
0x8aadb11 <pypy_g_OptHeap_emitting_operation+609>: jmp 0x8aadbbf <pypy_g_OptHeap_emitting_operation+783>
Whereas I'd expect more variation with an uninitialized variable. Valgrind does
not report any uninitialized variables either (other than PyObject_Free, which I'll
presume is there for the same reason as for CPython (?)):
When I select only the jit options that will not give me a segfault and then
run under valgrind, this is the only complaint I get (other than PyObject_Free):
==16681== Address 0x4b18010 is 3,352 bytes inside a block of size 4,100 free'd
==16681== at 0x40268A6: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==16681== by 0x811282C: pypy_g__ll_dict_setitem_lookup_done__DICTPtr_Address_Ad (in /home/wlav/pypydev/pypy/pypy/translator/goal/pypy-c)
Thanks,
Wim
--
WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
More information about the pypy-dev
mailing list