lcompilers / lpython

Python compiler
https://lpython.org/
Other
1.5k stars 158 forks source link

AddressSanitizer Errors for `test_dict_nested1.py` and `print_list_tuple_03.py`: requested allocation size exceeds maximum supported size #2595

Closed Vipul-Cariappa closed 5 months ago

Vipul-Cariappa commented 6 months ago

Steps to reproduce:

./src/bin/lpython ./integration_tests/test_dict_nested1.py
clang -L./src/runtime/ -llpython_runtime -lm -g -fsanitize=address -fno-omit-frame-pointer ./test_dict_nested1.out.tmp.o
LD_PRELOAD=./src/runtime/liblpython_runtime.so ./a.out

AddressSanitizer Output:

==119540==ERROR: AddressSanitizer: requested allocation size 0xfffffffffafafaf8 (0xfffffffffafb0af8 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)
    #0 0x6140945de9be in malloc /home/runner/work/llvm-project/llvm-project/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
    #1 0x776f5992ea0c in _lfortran_malloc /home/vipul/Workspace/python/lpython/src/libasr/runtime/lfortran_intrinsics.c:1645:12
    #2 0x61409461cdfe in __module___main___test_nested_dict (/home/vipul/Workspace/python/lpython/a.out+0x106dfe)
    #3 0x61409461b435 in __module___main_____main__global_stmts (/home/vipul/Workspace/python/lpython/a.out+0x105435)

==119540==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big /home/runner/work/llvm-project/llvm-project/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 in malloc
==119540==ABORTING

If I run it with allocator_may_return_null=1

❯ ASAN_OPTIONS="allocator_may_return_null=1" LD_PRELOAD=./src/runtime/liblpython_runtime.so ./a.out
==122213==WARNING: AddressSanitizer failed to allocate 0xfffffffffafafaf8 bytes
=================================================================
==122213==ERROR: AddressSanitizer: unknown-crash on address 0xbebebebebebebebe at pc 0x5a7abf10bad1 bp 0x7ffdca059750 sp 0x7ffdca058f08
READ of size 4210752248 at 0xbebebebebebebebe thread T0
    #0 0x5a7abf10bad0 in memcpy /home/runner/work/llvm-project/llvm-project/final/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:115:5
    #1 0x5a7abf14ae10 in __module___main___test_nested_dict (/home/vipul/Workspace/python/lpython/a.out+0x106e10)
    #2 0x5a7abf149435 in __module___main_____main__global_stmts (/home/vipul/Workspace/python/lpython/a.out+0x105435)
    #3 0x5a7abf14be9a in main (/home/vipul/Workspace/python/lpython/a.out+0x107e9a)
    #4 0x7cb4de029d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #5 0x7cb4de029e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #6 0x5a7abf06f344 in _start (/home/vipul/Workspace/python/lpython/a.out+0x2b344)

Address 0xbebebebebebebebe is a wild pointer inside of access range of size 0x0000fafafaf8.
SUMMARY: AddressSanitizer: unknown-crash /home/runner/work/llvm-project/llvm-project/final/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:115:5 in memcpy
==122213==ABORTING

You can preform similar steps with ./integration_tests/print_list_tuple_03.py.

Vipul-Cariappa commented 6 months ago

I have been debugging this for more than 4 hours. Looks like the issue is due to the use of uninitialized values. Valgrind Output

❯ valgrind --tool=memcheck --track-origins=yes ./tmp.out 
==683874== Memcheck, a memory error detector
==683874== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==683874== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==683874== Command: ./tmp.out
==683874== 
==683874== Conditional jump or move depends on uninitialised value(s)
==683874==    at 0x4848842: malloc (vg_replace_malloc.c:381)
==683874==    by 0x4867A8C: _lfortran_malloc (lfortran_intrinsics.c:1646)
==683874==    by 0x109D9E: __module___main_____main__global_init (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874==    by 0x109E1A: main (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874==  Uninitialised value was created by a heap allocation
==683874==    at 0x4848899: malloc (vg_replace_malloc.c:381)
==683874==    by 0x4867A8C: _lfortran_malloc (lfortran_intrinsics.c:1646)
==683874==    by 0x109B08: __module___main_____main__global_init (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874==    by 0x109E1A: main (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874== 
==683874== Conditional jump or move depends on uninitialised value(s)
==683874==    at 0x485288A: memmove (vg_replace_strmem.c:1382)
==683874==    by 0x109DB0: __module___main_____main__global_init (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874==    by 0x109E1A: main (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874==  Uninitialised value was created by a heap allocation
==683874==    at 0x4848899: malloc (vg_replace_malloc.c:381)
==683874==    by 0x4867A8C: _lfortran_malloc (lfortran_intrinsics.c:1646)
==683874==    by 0x109B08: __module___main_____main__global_init (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874==    by 0x109E1A: main (in /home/vipul/Workspace/python/lpython/tmp.out)
==683874== 
==683874== 
==683874== HEAP SUMMARY:
==683874==     in use at exit: 292 bytes in 19 blocks
==683874==   total heap usage: 22 allocs, 3 frees, 334 bytes allocated
==683874== 
==683874== LEAK SUMMARY:
==683874==    definitely lost: 137 bytes in 7 blocks
==683874==    indirectly lost: 16 bytes in 2 blocks
==683874==      possibly lost: 0 bytes in 0 blocks
==683874==    still reachable: 139 bytes in 10 blocks
==683874==         suppressed: 0 bytes in 0 blocks
==683874== Rerun with --leak-check=full to see details of leaked memory
==683874== 
==683874== For lists of detected and suppressed errors, rerun with: -s
==683874== ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)
Vipul-Cariappa commented 6 months ago

I found a weird thing. Most probably, due to the problem mentioned above (previous comment). When running the mentioned programs under gdb there is a call to _lfortran_malloc with size = 0 as an argument. I don't think this is intended.

image

Vipul-Cariappa commented 5 months ago

Closed by #2564.