core dump when calling the list aggregate function.

[yiyuanliu]

What happens?

create table tbl as select unnest(generate_series(500000000)) as id;
select list(id) from tbl;

Segmentation fault (core dumped)

To Reproduce

see above

OS:

ubuntu 2204

DuckDB Version:

v0.9.3-dev1411 7d5150c

DuckDB Client:

cli

Full Name:

Yiyuan Liu

Affiliation:

High-Flyer AI

Have you tried this on the latest main branch?

I have tested with a main build

Have you tried the steps to reproduce? Do they include all relevant data and configuration? Does the issue you report still appear there?

• Yes, I have

[szarnyasg]

Hi @yiyuanliu, this query completed on my MacBook Pro (32GB RAM).
How much memory / how many CPU core / what architecture (x86/arm64) did the machine have?
Of course, it should not result in a segfault even if the available resources are insufficient.

[yiyuanliu]

Hi @yiyuanliu, this query completed on my MacBook Pro (32GB RAM). How much memory / how many CPU core / what architecture (x86/arm64) did the machine have? Of course, it should not result in a segfault even if the available resources are insufficient.

The machine architecture is x64, containing 2 NUMA nodes with a total of 128 physical cores. My testing was carried out inside a container configured with 32 CPU cores and 64GB of memory. Under the default configuration of DuckDB, the number of threads is also set to 32 cores.

[yiyuanliu]

Hi @yiyuanliu, this query completed on my MacBook Pro (32GB RAM). How much memory / how many CPU core / what architecture (x86/arm64) did the machine have? Of course, it should not result in a segfault even if the available resources are insufficient.

This query also crashed on my MacBook Pro(M1 pro, 16GB RAM). It appears that the query itself executed successfully, but an incorrect memory address was accessed when converting the result to string for output.

(base) ➜  duckdb git:(main) ./build/release/duckdb
v0.9.3-dev1411 7d5150c198
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
D create table tbl as select unnest(generate_series(500000000)) as id;
100% ▕████████████████████████████████████████████████████████████▏
D select list(id) from tbl;
100% ▕████████████████████████████████████████████████████████████▏
[1]    53751 segmentation fault  ./build/release/duckdb

(base) ➜  duckdb git:(main) lldb ./build/release/duckdb
(lldb) target create "./build/release/duckdb"
Current executable set to '/Users/liuyiyuan/code/duckdb/build/release/duckdb' (arm64).
(lldb) r
Process 55274 launched: '/Users/liuyiyuan/code/duckdb/build/release/duckdb' (arm64)
v0.9.3-dev1411 7d5150c198
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
D create table tbl as select unnest(generate_series(500000000)) as id;
100% ▕████████████████████████████████████████████████████████████▏
D select list(id) from tbl;
Error: Out of Memory Error: failed to allocate data of size 512.0 MiB (12.4 GiB/12.7 GiB used)
Database is launched in in-memory mode and no temporary directory is specified.
Unused blocks cannot be offloaded to disk.

Launch the database with a persistent storage back-end
Or set PRAGMA temp_directory='/path/to/tmp.tmp'
D select list(id) from tbl;
100% ▕████████████████████████████████████████████████████████████▏
Process 55274 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3231202c35373133)
    frame #0: 0x000000018addb684 libsystem_platform.dylib`_platform_memmove + 52
libsystem_platform.dylib`:
->  0x18addb684 <+52>: ldnp   q2, q3, [x1]
    0x18addb688 <+56>: sub    x5, x3, x0
    0x18addb68c <+60>: add    x1, x1, x5
    0x18addb690 <+64>: ldnp   q0, q1, [x1]
Target 0: (duckdb) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3231202c35373133)
  * frame #0: 0x000000018addb684 libsystem_platform.dylib`_platform_memmove + 52
    frame #1: 0x00000001005dbbd4 duckdb`duckdb::ListToVarcharCast(duckdb::Vector&, duckdb::Vector&, unsigned long long, duckdb::CastParameters&) + 748
    frame #2: 0x00000001009fdc4c duckdb`duckdb::VectorOperations::TryCast(duckdb::CastFunctionSet&, duckdb::GetCastFunctionInput&, duckdb::Vector&, duckdb::Vector&, unsigned long long, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, bool) + 152
    frame #3: 0x00000001009fdf70 duckdb`duckdb::VectorOperations::Cast(duckdb::ClientContext&, duckdb::Vector&, duckdb::Vector&, unsigned long long, bool) + 84
    frame #4: 0x0000000100aeef00 duckdb`duckdb::BoxRenderer::FetchRenderCollections(duckdb::ClientContext&, duckdb::ColumnDataCollection const&, unsigned long long, unsigned long long) + 596
    frame #5: 0x0000000100aec484 duckdb`duckdb::BoxRenderer::Render(duckdb::ClientContext&, duckdb::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, true> const&, duckdb::ColumnDataCollection const&, std::__1::basic_ostream<char, std::__1::char_traits<char>>&) + 804
    frame #6: 0x0000000100aec0c4 duckdb`duckdb::BoxRenderer::ToString(duckdb::ClientContext&, duckdb::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, true> const&, duckdb::ColumnDataCollection const&) + 84
    frame #7: 0x000000010002717c duckdb`duckdb_shell_sqlite3_print_duckbox + 1456
    frame #8: 0x000000010001bcb8 duckdb`exec_prepared_stmt + 804
    frame #9: 0x000000010000f140 duckdb`shell_exec + 904
    frame #10: 0x000000010001cf48 duckdb`runOneSqlLine + 308
    frame #11: 0x000000010001011c duckdb`process_input + 1200
    frame #12: 0x0000000100007c04 duckdb`main + 4248
    frame #13: 0x000000018aa310e0 dyld`start + 2360