mysqld crash at duckdb::StandardBufferManager::EvictBlocksOrThrow with release builds

[meetamit77]

commit: 5992bff
branch: master

#0 __pthread_kill_implementation (threadid=281473450815552, signo=6, no_tid=)
at pthread_kill.c:44
#1 handle_fatal_signal (sig=6) at signal_handler.cc:232
#2
#3 __pthread_kill_implementation (threadid=281473450815552, signo=signo@entry=6,
no_tid=no_tid@entry=0) at pthread_kill.c:44
#4 __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#5 __GI_raise (sig=sig@entry=6) at raise.c:26
#6 __GI_abort () at abort.c:79
#7 __gnu_cxx::__verbose_terminate_handler() () from /lib/aarch64-linux-gnu/libstdc++.so.6
#8 ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
#9 std::terminate() () from /lib/aarch64-linux-gnu/libstdc++.so.6
#10 __cxa_throw () from /lib/aarch64-linux-gnu/libstdc++.so.6
#11 duckdb::StandardBufferManager::EvictBlocksOrThrow<char const*, std::__cxx11::basic_string<char, std::char_traits, std::allocator > > (this=this@entry=,
tag=tag@entry=duckdb::MemoryTag::BASE_TABLE, memory_delta=memory_delta@entry=262144,
buffer=buffer@entry=) at new_allocator.h:104
#12 duckdb::StandardBufferManager::Pin (this=, handle=...) at standard_buffer_manager.cpp:360

1. Create a fresh datadir with --initialize-insecure
2. Start the server with the following duckdb parameters
   --duckdb_mode=ON --force_innodb_to_duckdb=ON --duckdb_memory_limit=2147483648 --duckdb_threads=0
3. Create a table

DROP TABLE IF EXISTS t1;
CREATE TABLE t1(pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY, c1 VARCHAR(255));
INSERT INTO t1(c1) values("how"),("y"),(REPEAT("asda",15));

4. Stop the server and restart without the duckdb parameters

mysqld crashes

[p1p1bear]

Thanks for the detailed report and the stack trace.

I haven’t been able to reproduce the issue on my side for now. That said, based on the stack trace, it appears the failure may be related to an exception thrown after DuckDB performs memory eviction. It is also possible that this is related to a bug in DuckDB v1.3.2.

From the scenario you described, restarting the server without the DuckDB-related startup parameters after previously running with them enabled seems like a case that may require additional handling on our side.

One possible direction would be to prevent access to DuckDB-backed tables when duckdb_mode=OFF. Another option would be to ensure that the DuckDB engine remains available by default. In any case, this behavior likely needs further refinement, and we will take this into consideration as we review the design.

Thanks again for the report.