[pypy-dev] PPC64 backend compile_framework_7_interior failure

[Maciej Fijalkowski]

On Fri, Aug 24, 2012 at 2:50 AM, David Edelsohn <dje.gcc at gmail.com> wrote:
> 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 at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

Hi David.

Can you get the traces dumped so we can see? If you can get the
jitviewer running, it'll show you the assembler mixed with resops. If
not, you can try to fish the resops yourself (they contain the actual
offset inside assembler). Let me know if you need some help with that.