Hi, with the Reflex branch, and the fast path enabled, I sometimes run into pbs with doubles in libffi. Sometimes the results are wrong, sometimes there's a crash, and sometimes there's: self = <C object ffi_cif (opaque) at 0xbfb8848> def _ctypes_storage_was_allocated(self): addr = ctypes.cast(self._storage, ctypes.c_void_p).value if addr in ALLOCATED:
raise Exception("internal ll2ctypes error - "
"double conversion from lltype to ctypes?") E Exception: internal ll2ctypes error - double conversion from lltype to ctypes? Any ideas? Thanks, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi Wim, On 11/29/2010 02:17 PM, wlavrijsen@lbl.gov wrote:
Given that we are not running PyPy's test suite on PyPy nightly currently, I think it would be safer to keep running the tests on top of CPython. Running the tests needs ctypes, and I don't quite trust PyPy's implementation of that yet (there are even known bugs that have not been fixed on trunk but only on a branch). You should still be able to use pypy-c-jit for translation, because for translation (and after translation) you won't need ctypes that much. Cheers, Carl Friedrich
Hi Carl, well, the real problem started when trying to use pythonify.py as that gives me a segfault in: Program received signal SIGSEGV, Segmentation fault. 0x0865b98c in pypy_g_BuiltinActivation_UwS_W_CPPOverload__run () (gdb) where #0 0x0865b98c in pypy_g_BuiltinActivation_UwS_W_CPPOverload__run () #1 0xb7933fe4 in ?? () #2 0x00000000 in ?? () I then moved to the test and the segfault there (if the exception is not seen) is the same. Hence I was hoping that the exception provided some insight into the source of the segfault. The benchmark uses .invoke(), so bypasses pythonify, but for a demo, I prefer the syntax that pythonify offers I'll do some more digging first. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi Carl,
Given that we are not running PyPy's test suite on PyPy nightly currently, I think it would be safer to keep running the tests on top of CPython.
of course, that begs the question how one tests pypy? I'm thinking of making the benchmarks more elaborate and use those as my post-translation tests. Btw., I solved the original segfault that I was after, but that didn't change anything for the particular error in this e-mail thread, though. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi Wim, On 11/29/2010 02:17 PM, wlavrijsen@lbl.gov wrote:
Given that we are not running PyPy's test suite on PyPy nightly currently, I think it would be safer to keep running the tests on top of CPython. Running the tests needs ctypes, and I don't quite trust PyPy's implementation of that yet (there are even known bugs that have not been fixed on trunk but only on a branch). You should still be able to use pypy-c-jit for translation, because for translation (and after translation) you won't need ctypes that much. Cheers, Carl Friedrich
Hi Carl, well, the real problem started when trying to use pythonify.py as that gives me a segfault in: Program received signal SIGSEGV, Segmentation fault. 0x0865b98c in pypy_g_BuiltinActivation_UwS_W_CPPOverload__run () (gdb) where #0 0x0865b98c in pypy_g_BuiltinActivation_UwS_W_CPPOverload__run () #1 0xb7933fe4 in ?? () #2 0x00000000 in ?? () I then moved to the test and the segfault there (if the exception is not seen) is the same. Hence I was hoping that the exception provided some insight into the source of the segfault. The benchmark uses .invoke(), so bypasses pythonify, but for a demo, I prefer the syntax that pythonify offers I'll do some more digging first. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi Carl,
Given that we are not running PyPy's test suite on PyPy nightly currently, I think it would be safer to keep running the tests on top of CPython.
of course, that begs the question how one tests pypy? I'm thinking of making the benchmarks more elaborate and use those as my post-translation tests. Btw., I solved the original segfault that I was after, but that didn't change anything for the particular error in this e-mail thread, though. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
participants (2)
-
Carl Friedrich Bolz -
wlavrijsen＠lbl.gov