ludnic
commented
1 year ago @freevryheid would you mind taking a look at the data chunk interface and let me know if you think this looks alright? the test doesn't trigger these yet because of the chunk_count error.
Started looking into the duckdb_result_chunk_count functions which is giving a memory error. The implementation mirrors the columns_count function so not sure why this one is not working.
run valgrind on the test below shows the error comes from that function but no other clues.
valgrind output
```shell root@0671f8782815:/workspaces/duckdb# fpm test --runner='valgrind --track-origins=yes' Project is up to date ==8033== Memcheck, a memory error detector ==8033== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8033== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==8033== Command: build/gfortran_2A42023B310FA28D/test/duckdb-test ==8033== # Testing: starting_database Starting simple-startup ... (1/2) ... simple-startup [PASSED] Starting multiple-startup ... (2/2) ... multiple-startup [PASSED] # Testing: test_fortran_api Starting basic-api-test ... (1/8) ... basic-api-test [PASSED] Starting basic-null-test ... (2/8) ... basic-null-test [PASSED] Starting basic-string-test ... (3/8) ... basic-string-test [PASSED] Starting basic-bool-test ... (4/8) ... basic-bool-test [PASSED] Starting basic-insert-test ... (5/8) ... basic-insert-test [PASSED] Starting basic-errors-test ... (6/8) ... basic-errors-test [PASSED] Starting parquet-api-test ... (7/8) ... parquet-api-test [PASSED] Starting data-chunk-test ... (8/8) ==8033== Invalid read of size 8 ==8033== at 0x59C6358: duckdb_result_chunk_count (in /usr/local/lib/libduckdb.so) ==8033== by 0x1104EB: __duckdb_MOD_duckdb_result_chunk_count (duckdb.f90:1234) ==8033== by 0x10B9F7: __test_fortran_api_MOD_test_data_chunk (test_fortran_api.f90:476) ==8033== by 0x11CC17: __testdrive_MOD_run_unittest (testdrive.F90:392) ==8033== by 0x11D537: __testdrive_MOD_run_testsuite (testdrive.F90:336) ==8033== by 0x10A95F: MAIN__ (main.f90:19) ==8033== by 0x10AA47: main (main.f90:3) ==8033== Address 0x2e is not stack'd, malloc'd or (recently) free'd ==8033== Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x6bad08b in ??? #1 0x6bac047 in ??? #2 0x580b917f in ??? #3 0x59c6358 in ??? #4 0x1104eb in __duckdb_MOD_duckdb_result_chunk_count at ./src/duckdb.f90:1234 #5 0x10b9f7 in test_data_chunk at test/test_fortran_api.f90:476 #6 0x11cc17 in run_unittest at build/dependencies/test-drive/src/testdrive.F90:392 #7 0x11d537 in __testdrive_MOD_run_testsuite at build/dependencies/test-drive/src/testdrive.F90:336 #8 0x10a95f in tester at test/main.f90:19 #9 0x10aa47 in main at test/main.f90:3 ==8033== ==8033== Process terminating with default action of signal 11 (SIGSEGV) ==8033== at 0x6E3F200: __pthread_kill_implementation (pthread_kill.c:44) ==8033== by 0x6DFA67B: raise (raise.c:26) ==8033== by 0x580B917F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==8033== ==8033== HEAP SUMMARY: ==8033== in use at exit: 1,271,842 bytes in 8,363 blocks ==8033== total heap usage: 422,242 allocs, 413,879 frees, 62,431,997 bytes allocated ==8033== ==8033== LEAK SUMMARY: ==8033== definitely lost: 848 bytes in 30 blocks ==8033== indirectly lost: 13,811 bytes in 188 blocks ==8033== possibly lost: 125,120 bytes in 44 blocks ==8033== still reachable: 1,132,063 bytes in 8,101 blocks ==8033== of which reachable via heuristic: ==8033== newarray : 31,368 bytes in 1 blocks ==8033== suppressed: 0 bytes in 0 blocks ==8033== Rerun with --leak-check=full to see details of leaked memory ==8033== ==8033== For lists of detected and suppressed errors, rerun with: -s ==8033== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault Execution failed for object " duckdb-test "
*cmd_run*:stopping due to failed executions
STOP 1
```