Seg Fault for case involving symbolic lists through llvm backend

[anutosh491]

Consider the following example

from lpython import S
from sympy import Symbol, pi

def mmrv() -> list[S]:
    l1: list[S] = [pi]
    return l1

def test_mrv1():
    ans: list[S] = mmrv()
    el: S = ans[0]
    print(el)

test_mrv1()

We get

(lf) anutosh491@spbhat68:~/lpython/lpython$ lpython --enable-symengine --backend=llvm examples/expr2.py 
Segmentation fault

The same function would work for a list of any other type but fails to work for a symbolic list.

[anutosh491]

After debugging this I see that the error occurs due to the extraction of element from the list ans[0].
The final ASR after all passes and the llvm IR look good to me.

[certik]

This works:

def mmrv() -> list[i32]:
    l1: list[i32] = [5]
    return l1

def test_mrv1():
    ans: list[i32] = mmrv()
    el: i32 = ans[0]
    print(el)

test_mrv1()

So we can compare it against the CPtr version after the symbolic pass and see what the problem is. Things to try:

• You can then try to reproduce it by explicitly writing Python code that uses CPtr (does not use the symbolic pass) and we need to figure out why it segfaults.
• Use lpython d.py --show-c, compile the C code and see if it segfaults the same way. If it does, debug the C code only using clang. If it doesn't, figure out what is different to the LLVM code.
• When debugging the C code, you can use lldb to figure out why it segfaults.

[anutosh491]

I was almost able to figure this out. Now that #2453 & #2454 have gone in, we have the llvm and c backend ready to deal with any symbolic container like a symbolic list.

So consider the following. We expect the program given above to transform to something like this (in python) after the symbolic and the subroutine_from_function pass

from lpython import S
from sympy import Symbol, pi

def mmrv(r: Out[list[S]]) -> None:
    x: S = pi
    l1: list[S] = [x]
    r = l1

def test_mrv2():
    ans: list[S]
    temp: list[S]
    mmrv(temp)
    ans = temp
    print(ans[0])

test_mrv2()

Now this gives us a segmentation fault both through the llvm and the c backend

(lf) anutosh491@spbhat68:~/lpython/lpython$ lpython --enable-symengine integration_tests/test_gruntz.py --backend=c
Segmentation fault
(lf) anutosh491@spbhat68:~/lpython/lpython$ lpython --enable-symengine integration_tests/test_gruntz.py --backend=llvm
Segmentation fault

But what works is this

from lpython import S
from sympy import Symbol, pi

def mmrv(r: Out[list[S]]) -> None:
    x: S = pi
    l1: list[S] = [x]
    r = l1

def test_mrv2():
    ans: list[S]
    mmrv(ans)
    print(ans[0])

test_mrv2()

(lf) anutosh491@spbhat68:~/lpython/lpython$ lpython --enable-symengine integration_tests/test_gruntz.py --backend=c
pi
(lf) anutosh491@spbhat68:~/lpython/lpython$ lpython --enable-symengine integration_tests/test_gruntz.py --backend=llvm
pi

[anutosh491]

So basically the subroutine_from_function pass, alters two steps which are

1. passing a temp variable (__libasr__created__var__0__func_call_res) to the SubRoutine
2. Assign the temp variable back to ans

Not that this is wrong but the step 2 here is responsible for the issues through both backends. Considering the C backend. All code is same for both the code snippets above except 3 lines

void test_mrv2()
{
    struct list_CPtr ans;
    mmrv(&ans);
    printf("%s\n", basic_str(ans.data[0]));
}

void test_mrv2()
{
    struct list_CPtr ans;
    struct list_CPtr temp;
    mmrv(&temp);
    list_deepcopy_CPtr(&temp, &ans);

    printf("%s\n", basic_str(ans.data[0]));
}

The first one works the second gives us a segmentation fault.

[Thirumalai-Shaktivel]

Here, the following doesn't seg fault. I think the issue might be either with print statement or basic_str. What do you think?

from lpython import S
from sympy import Symbol, pi

def mmrv(r: Out[list[S]]) -> None:
    x: S = pi
    l1: list[S] = [x]
    r = l1

def test_mrv2():
    ans: list[S]
    temp: list[S]
    mmrv(temp)
    ans = temp
    x: S = ans[0]
    print(x)

test_mrv2()

[anutosh491]

Wait it doesn't seg fault for you ? It does for me !
My thinking says it's still the deep copy that is at fault both through the llvm and the C backend. The working example I've provided above works both with the llvm and the c backend. If you want to try the C backend out ( the PR is here #2454 , the tests through macos fail for an unknown reason)

[certik]

On the last Python example, both of these things fail for me:

$ lpython --backend=c a.py -o xx --enable-symengine
$ ./xx                                             
zsh: bus error  ./xx
$ lpython --backend=llvm a.py -o yy --enable-symengine
$ ./yy 
zsh: segmentation fault  ./yy

We need to debug it and fix it. Let's start with the C code, compile it using Clang, and figure out why it segfaults.

[anutosh491]

@certik @Thirumalai-Shaktivel
I have been trying to debug this for a couple of days but sadly haven't made progress yet.

I am not sure but I think I am stuck with a couple of issues.

1. Consider the following

 from lpython import S
from sympy import Symbol, pi

def mmrv(r: Out[list[S]]) -> None:
    x: S = pi
    l1: list[S] = [x]
    r = l1

def test_mrv2():
    ans: list[S]
    mmrv(ans)
    x: S = ans[0]
    print(x)

test_mrv2()

When I execute it through lpython, it works

(lf) anutosh491@spbhat68:~/lpython/lpython$ lpython --enable-symengine --backend=c integration_tests/test_gruntz.py 
pi

But when I copy the generated C code (from test_gruntz_tmp__generated__.c to expr.c )

(lf) anutosh491@spbhat68:~/lpython/lpython$ clang -I${CONDA_PREFIX}/include -c expr.c -o expr.o -I src/libasr/runtime/
(lf) anutosh491@spbhat68:~/lpython/lpython$ clang -o expr.out expr.o -L$CONDA_PREFIX/lib -Wl,-rpath -Wl,$CONDA_PREFIX/lib -lsymengine -L src/runtime -llpython_runtime
(lf) anutosh491@spbhat68:~/lpython/lpython$ LD_LIBRARY_PATH=src/runtime ./expr.out
Segmentation fault

Not sure why this might be happening. I think the commands I'm executing are correct

[anutosh491]

2. I thought this has something to do with list_deepcopy_CPtr but then I checked it out through multiple different scenarios and I think what might be at fault is the basic_str function. Consider the following C code

void mmrv(struct list_CPtr *r)
{
    int64_t _x;
    struct list_CPtr l1;
    void* x;
    _x = 0;
    x = NULL;
    x = (void*) &_x;
    basic_new_stack(x);
    basic_const_pi(x);
    struct list_CPtr constname0;
    list_init_CPtr(&constname0, 1);
    constname0.data[0] = x;
    constname0.current_end_point = 1;
    list_deepcopy_CPtr(&constname0, &l1);

    list_deepcopy_CPtr(&l1, r);
    printf("%p\n", r->data[0]);
    printf("%s\n", basic_str(r->data[0]));

    basic_free_stack(x);
}

void test_mrv2()
{
    int64_t _x;
    struct list_CPtr ans;
    struct list_CPtr temp;
    void* x;
    _x = 0;
    x = NULL;
    x = (void*) &_x;
    basic_new_stack(x);
    mmrv(&temp);

    // Print information about temp
    printf("temp capacity: %d\n", temp.capacity);
    printf("temp current_end_point: %d\n", temp.current_end_point);
    printf("temp data:\n");
    for (int i = 0; i < temp.current_end_point; ++i) {
        printf("  %p\n", temp.data[i]);
        printf("%s\n", basic_str(temp.data[i]));
    }

    list_deepcopy_CPtr(&temp, &ans);

    basic_assign(x, ans.data[0]);
    printf("%s\n", basic_str(x));
    basic_free_stack(x);
}

We are trying to print the exact same things from both the functions mmrv and test_mrv2. Even the reference being printed out is the same. And the result I get is this

(lf) anutosh491@spbhat68:~/lpython/lpython$ LD_LIBRARY_PATH=src/runtime ./expr.out
0x7ffc88087b00
pi
temp capacity: 1
temp current_end_point: 1
temp data:
  0x7ffc88087b00
Segmentation fault

[certik]

I compile the example like this:

clang -g -I${CONDA_PREFIX}/include -c expr.c -o expr.o -I src/libasr/runtime/
clang -g -o expr.out expr.o -L$CONDA_PREFIX/lib -Wl,-rpath -Wl,$CONDA_PREFIX/lib -Wl,-rpath -Wl,src/runtime -lsymengine -L src/runtime -llpython_runtime

Debug like this:

$ lldb ./expr.out 
(lldb) target create "./expr.out"
Current executable set to '/Users/ondrej/repos/lpython/expr.out' (arm64).
(lldb) run
Process 93807 launched: '/Users/ondrej/repos/lpython/expr.out' (arm64)
Process 93807 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1000035f4)
    frame #0: 0x0000000102b37e10 libsymengine.0.11.dylib`basic_assign + 32
libsymengine.0.11.dylib`basic_assign:
->  0x102b37e10 <+32>: ldaddal w9, w8, [x8]
    0x102b37e14 <+36>: ldr    x8, [x19]
    0x102b37e18 <+40>: cbz    x8, 0x102b37e44           ; <+84>
    0x102b37e1c <+44>: add    x8, x8, #0x8              ; =0x8 
Target 0: (expr.out) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1000035f4)
  * frame #0: 0x0000000102b37e10 libsymengine.0.11.dylib`basic_assign + 32
    frame #1: 0x00000001000035a4 expr.out`test_mrv2 at expr.c:76:5
    frame #2: 0x00000001000035e4 expr.out`__main__global_stmts at expr.c:83:5
    frame #3: 0x000000010000361c expr.out`main(argc=1, argv=0x000000016fdff7c8) at expr.c:89:5
    frame #4: 0x00000001000110f4 dyld`start + 520

The problem is in this function:

void mmrv(struct list_CPtr *r)
{
    int64_t _x;
    struct list_CPtr l1;
    void* x;
    _x = 0;
    x = NULL;
    x = (void*) &_x;
    basic_new_stack(x);
    basic_const_pi(x);
    struct list_CPtr constname0;
    list_init_CPtr(&constname0, 1);
    constname0.data[0] = x;
    constname0.current_end_point = 1;
    list_deepcopy_CPtr(&constname0, &l1);

    list_deepcopy_CPtr(&l1, r);

    basic_free_stack(x);
}

Where _x is a local variable, which holds the storage of x. And the variable goes out of scope and then it segfaults, since the memory is not there anymore. An easy quick fix is to move the line int64_t _x; into global scope, then it works:

$ clang -g -I${CONDA_PREFIX}/include -c expr.c -o expr.o -I src/libasr/runtime/ && clang -g -o expr.out expr.o -L$CONDA_PREFIX/lib -Wl,-rpath -Wl,$CONDA_PREFIX/lib -Wl,-rpath -Wl,src/runtime -lsymengine -L src/runtime -llpython_runtime && ./expr.out
pi

The corresponding Python function is:

def mmrv(r: Out[list[S]]) -> None:
    x: S = pi
    l1: list[S] = [x]
    r = l1

The problem is with the line:

    constname0.data[0] = x;

it needs to be replaced with:

    constname0.data[0] = basic_new_heap();               
    basic_assign(constname0.data[0], x);   

Then it works. There are two bugs. The constname0.data[0] is not initialized. The second bug is that we cannot copy using the C = operator, but rather we always have to use basic_assign for any kind of copy of symbolic objects, which automatically handles the reference counting underneath. Note that the variable that we assign to must be initialized with either basic_new_heap or with basic_new_stack.

To fix this, there are two bugs:

• The simpler bug is that conceptually l1[0] = x has to be replaced by basic_assign(constname0.data[0], x);, not by constname0.data[0] = x;. In other words, we need to change constname0.data[0] = x into basic_assign(constname0.data[0], x).
• The second bug is that l1[0] must be initialized using basic_new_heap. When the List gets initialized in C, it is done using the following code: struct list_CPtr constname0; list_init_CPtr(&constname0, 1); and that would be enough if the element type was an int. But because the element type is a symbolic expression, we also need to add there a line constname0.data[0] = basic_new_heap();. More likely it would be a loop over all elements and calling basic_new_heap() on all elements.

(Also it seems the list is currently leaking memory, it seems it is never destroyed. But once we implement list destorying, we also have to call basic_free_heap() on each element there.)

Specifically, to make progress, let's follow the usual approach. Take the code:

def mmrv(r: Out[list[S]]) -> None:
    x: S = pi
    l1: list[S] = [x]
    r = l1

And figure out LPython code that uses the symengine API directly.

def mmrv(r: Out[list[S]]) -> None:
    # x: S = pi
    x: CPtr = basic_new_heap()
    basic_const_pi(x)
    # l1: list[S]
    l1: list[CPtr]
    for i in range(1):
        tmp: CPtr = basic_new_heap()
        l1.append(tmp)
    # l1 = [x]
    basic_assign(l1[0], x)
    # r = l1
    ...

TODO:

• Just figure out how the code should look like, no ASR symbolic pass is needed. Make sure it works both in C and LLVM backends.
• Once that works, then we add these translation operations into the symbolic ASR backend.

Note: in LPython, list assignment r = l1 is always a deep copy (unlike in CPython where it is just a refcount increase), so we should initialize r first using basic_new_heap and then use basic_assign to assign the elements. That can be done later. The LPython semantics requires that l1 is not used after it is assigned to r, to keep the semantics equal to CPython.

[anutosh491]

Can be closed as the issue has been correctly fixed through #2465 & #2477