Armin, et al, compile_framework_7_interior in test_zrpy_gc fails for the PPC64 backend in a strange way. Identical problems happen on the public system and my private system, but GDB on the public system is not permitting hardware watchpoints, so it is more difficult to catch the cause of the failure.
The testcase segfaults in a load following the instructions generated for getinteriorfield_gc: 0xfffb74e1958: li r3,0 0xfffb74e195c: li r0,24 0xfffb74e1960: mullw r0,r3,r0 0xfffb74e1964: addic r0,r0,16 0xfffb74e1968: ldx r3,r30,r0 ; $r30 + $r0 = 0xfffb75ea030 => 0xfffb74e196c: ld r3,8(r3) ; $r3 = 904 The ldx is the load from getinteriorfield_gc and the subsequent load fails. "904" appears to correspond to "n + i * 100 + ..." in the testcase for i = 9. If I set a watchpoint on the address, it initially is written during memcpy of a minor collection: #0 0x00000fffb7d0daa0 in .memcpy () from /lib64/power7/libc.so.6 #1 0x000000001000fb0c in .pypy_g_trace___trace_drag_out () #2 0x0000000010014288 in .pypy_g_MiniMarkGC_collect_oldrefs_to_nursery () #3 0x0000000010015358 in .pypy_g_MiniMarkGC_minor_collection.part.0 () #4 0x000000001001ce04 in .pypy_g_MiniMarkGC_collect () at which point (gdb) x/gx 0xfffb75ea030 0xfffb75ea030: 0x00000fffb776c170 (gdb) x/gd 0x00000fffb776c170 0xfffb776c170: 904 In other words, the location contains a pointer to another location containing the value "904". The value at that location later is overwritten in jitted code: 0xfffb74e0dec: li r28,0 0xfffb74e0df0: li r0,24 0xfffb74e0df4: mullw r0,r28,r0 0xfffb74e0df8: addic r0,r0,16 0xfffb74e0dfc: stdx r3,r30,r0 0xfffb74e0e14: li r4,16 0xfffb74e0e18: add r4,r3,r4 0xfffb74e0e1c: li r3,904 0xfffb74e0e20: std r3,0(r4) ; $r4 = 0xfffb75ea030 (gdb) print/x $r4 $6 = 0xfffb75ea030 $r3 is stored as part of a setinteriorfield_gc sequence. Subsequently $r3+16 is used as an address to store "904". So now that location instead of containing a pointer to the value "904" has been overwritten with the value "904", which fails when it later is accessed. I don't know if this flattening is intentional and the code reading the value was not updated to compensate for some sort of unboxing or one level of indirection has been lost. Any guidance to help debug this would be appreciated. Thanks, David _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
