mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 04:54:13 +02:00
ispyisail
3fa5e0a475
A <graphics_table>'s <query> is stored in the .qet and executed when the project loads. SQLite produces rows lazily, so the cost of that query is not bounded by anything the project contains -- it is bounded by how long the loop reading the rows is willing to run. A recursive CTE takes one line to make that forever: WITH RECURSIVE c(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM c) SELECT n ... Put that in the <query> of any project's summary table and opening the file pins a core at 100% and grows ProjectDBModel::m_record until memory runs out. Measured on examples/industrial.qet with the query swapped, built from master: clean --export-bom 3.6 s, 396 rows, exit 0 poisoned --export-bom killed at 90 s, still going, no output No scripting, no MCP, no flag beyond an ordinary export. Opening the file in the editor is the same code path. QetScriptApi::query() has the identical loop, and the script engine's own 30 s interrupt does not reach it: that aborts JavaScript, and this is C++ inside a single call. Left alone it hung a --run for 45 s until the harness killed it. Both loops now stop at projectDataBase::MaxResultRows (100000) and say so. That is a backstop, not a page size: the largest table in the shipped examples is 396 rows, and a caller that reaches 100000 has been handed something it should not run to completion. It is not silent either way -- the model logs the offending query text, and qet.query() sets queryError(), so a truncated result is never mistaken for a complete one. clean --export-bom 3.6 s, 396 rows, exit 0 (unchanged) poisoned --export-bom 20.2 s, 396 rows, exit 0, warning names the query qet.query(recursive CTE) 3.8 s, 100000 rows, queryError() set Reverting each cap restores the hang, so both checks discriminate. Related to #983, which fixes a different flaw reachable through the same stored query. Neither depends on the other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>