Bug: SIGSEGV in the cached-prepared-statement path on a read-only workload in main (workaround: enable_cached_prepared_statement='NONE')

[jpbarbosa]

Ladybug version

main @ 520abda2c (after 0.20.1, so it includes #878). Released 0.18.3 is clean on the same workload.

What operating system are you using?

Linux aarch64 (python:3.14-slim container), Python 3.14, make python build.

What happened?

SIGSEGV on a read-only workload after a few hundred parameterized queries. Individual queries are fine; it needs volume. CALL enable_cached_prepared_statement='NONE' avoids it completely, and with that set the identical workload runs clean, so it looks confined to the cached-plan path.

Backtrace (Release build, so the inner frames are inlined):

#0-#4  ?? in _lbug.cpython-314-aarch64-linux-gnu.so
#5  lbug::main::ClientContext::TransactionHelper::runFuncInTransaction(
        transaction::TransactionContext&, std::function<void ()> const&, bool, bool,
        ClientContext::TransactionHelper::TransactionCommitAction)
#6  lbug::main::ClientContext::executeNoLock(
        main::PreparedStatement*, main::CachedPreparedStatement*,
        std::optional<unsigned long>, ClientContext::QueryConfig, bool)
#7  lbug::main::ClientContext::executeWithParams(...)
#8  lbug::main::Connection::executeWithParams(...)

Are there known steps to reproduce?

I could not reduce it to a synthetic repro, which is the weakness of this report. It reproduces reliably against my own ~130 MB database (a Japanese dictionary: Word/Reading/Sense/Kanji node tables plus rel tables) driven by ~60 mixed queries per round, crashing within 3 rounds. Reduced attempts that all survived 3400 executions on a synthetic 500-node database:

• one repeated parameterized statement, in each of: plain scan, ORDER BY, 1-hop traversal, aggregate + ORDER BY, LIMIT, OPTIONAL MATCH
• 20 / 100 / 300 structurally distinct parameterized statements, repeated (cache-pressure hypothesis)

So the trigger needs something I have not isolated. Given the stack and that disabling the statement cache is a complete workaround, I am reporting it rather than sitting on it, since it is adjacent to the #877 / #875 area that changed today. Happy to run patches or instrumented builds against the dataset that does reproduce it.

[adsharma]

Thank you for the report. The caching optimization is a big win on performance. One way to get to the bottom of this is to run your workload with a TSAN build. Recipe here.