[pypy-dev] PyPy PPC64 Prolog translation

[David Edelsohn]

Trying to keep everyone informed about what I learn while debugging
the PPC backend and get some help with next step in analysis.

The translated version of the Prolog interpreter (without JIT) runs
for most examples, but crashes for on one.  I recompiled the
interpreter with "-O1 -g" to get a better traceback.

$ pyrolog-c iter.pl
>?- iterate_findall(10000).

Program received signal SIGSEGV, Segmentation fault.
pypy_g_throw (l_exc_1=0xfffb76a99c0, l_scont_4=<value optimized out>,
    l_fcont_4=<value optimized out>, l_heap_6=<value optimized out>)
    at interpreter_continuation.c:6580
6580		l_v161545 = (struct pypy_object_vtable0
*)_OP_GET_NEXT_GROUP_MEMBER((&pypy_g_typeinfo),
(pypy_halfword_t)l_v161544->_gcheader.h_tid, sizeof(struct
pypy_type_info0));
(gdb) where
#0  pypy_g_throw (l_exc_1=0xfffb76a99c0, l_scont_4=<value optimized out>,
    l_fcont_4=<value optimized out>, l_heap_6=<value optimized out>)
    at interpreter_continuation.c:6580
#1  0x000000001010f8b8 in pypy_g_driver (l_scont_1=<value optimized out>,
    l_fcont_1=<value optimized out>, l_heap_2=<value optimized out>)
    at interpreter_continuation.c:3192
#2  0x0000000010116a30 in pypy_g_run (l_query_201=<value optimized out>,
    l_var_to_pos_4=0xfffb76a9748) at interpreter_translatedmain.c:2120
#3  0x000000001011861c in pypy_g_repl () at interpreter_translatedmain.c:231
#4  0x000000001010bf58 in pypy_g_entry_point (l_argv_1=<value optimized out>)
    at targetprologstandalone.c:242
#5  0x0000000010003708 in pypy_main_function (argc=<value optimized out>,
    argv=<value optimized out>)
    at /home/dje/src/pypy-ppc/pypy/translator/c/src/main.h:62
#6  0x00000fffb7c9f05c in .generic_start_main () from /lib64/power7/libc.so.6
#7  0x00000fffb7c9f27c in .__libc_start_main () from /lib64/power7/libc.so.6
#8  0x0000000000000000 in ?? ()

The following blocks from interpreter_continuation.c:pypy_g_throw()
lead to the segfault, but I am not sure why the data structure is
initialized with a bad value:

6574	    block0:
6575		l_heap_689 = l_heap_6;
6576		l_scont_245 = l_scont_4;
6577		goto block1;
6578	
6579	    block1:
6580		l_v161066 = (struct pypy_object0 *)l_scont_245;
6581		l_v161067 = (struct pypy_object_vtable0
*)_OP_GET_NEXT_GROUP_MEMBER((&pypy_g_typeinfo),
(pypy_halfword_t)l_v161066->_gcheader.h_tid, sizeof(struct
pypy_type_info0));
6582		l_v161068 = (struct
pypy_prolog_interpreter_continuation_Continuation_vtabl0 *)l_v161067;
6583		l_v161069 = RPyField(l_v161068, c_cls_is_done);

...

6736	    block19:
6737		l_v161116 = RPyField(l_scont_245, c_inst_nextcont);
6738		l_scont_245 = l_v161116;
6739		goto block1;

l_scont_245 is correct upon initial entry (assigned from l_scont_4
argument). Execution flows through block19 3 times before the crash.
On the third "iteration", l_scont_245 is set to 0, then dereferenced
in block0, causing a segfault.

pypy_g_throw() is entered with the chain of continuations (I assume
that is what c_inst_nextcont means) already containing a NULL.

>?- iterate_findall(10000).

Breakpoint 1, pypy_g_throw (l_v161056=0xfffb76a99c0, l_scont_4=0xfffb76a98a0,
    l_fcont_4=0xfffb76a9748, l_heap_6=0xfffb76a9778)
    at interpreter_continuation.c:6581
(gdb) x/4x l_scont_4
0xfffb76a98a0:	0x00000000	0x00000fb0	0x00000fff 	0xb76a9728
(gdb) x/4x 0xfffb76a9728
0xfffb76a9728:	0x00000000	0x000037f0	0x00000fff 	0xb76a95e8
(gdb) x/4x 0xfffb76a95e8
0xfffb76a95e8:	0x00000000	0x00003ad8	0x00000000	0x00000000

The third and forth values are the 64 bit address of the next field in
the chain.

I am not sure how this chain of continuations is initialized, but one
element contains a NULL pointer.

Thanks, David