firebird
firebird copied to clipboard
FirebirdSQL
FB crashes when evaluating too long expression [CORE6223]
Submitted by: @pavel-zotov
Duplicates CORE395
Attachments: eval-too-long-expr-leads-fb-to-crash.7z
There is completely pointless expression like this:
select x+x+ ... repeated lot of times ... + x+x from ( select cast(1. as double precision) / cast(5. as double precision) as x from rdb$database );
After number of terms ('x') in this expression will achieve ~20'037 FB will crash. First will 'give up' Classic, then SuperServer.
Checked on: WI-T4.0.0.1714 Cs WI-T4.0.0.1715 SS WI-V3.0.5.33221 - CS and SS
Dumps and stack traces can be found here:
https://drive.google.com/open?id=1GMhYG3hIoKYonSmxGoKtXMw-6QowzFmj
Expressions (two .sql scripts, they differs only in one term which causes crash in 3.0 CS; see that link) are in file:
eval-too-long-expr-leads-fb-to-crash.7z (see also attach to this ticket)
Modified by: @pavel-zotov
Attachment: eval-too-long-expr-leads-fb-to-crash.7z [ 13413 ]
Commented by: @pavel-zotov
PS. What looks weird is that duration of work this script before it crashes in FB can strongly vary: from ~40s for odd to 5-10 s for even runs. Also, it looks bad that such evaluating lead one CPU core to be loaded ~100% for such long time. This can be easy used for DoS attack on server.
Commented by: @dyemanov
Stack overflow, I suppose. I doubt we can do anyhting with that in the short term. Maybe only report this error properly on Windows (we do that for stack overflows during query execution, but not for preparation).
Commented by: @pavel-zotov
> Duplicate for CORE395?
Yes, exactly. But ticket 395 has less terms (maybe because older version of FB crashed earlier :))
Commented by: @pavel-zotov
> only report this error properly on Windows
Of course, it will be anyway better that crash. But what about cpu overload for ~100% during this evaluation ? Can this be avoided ?
Commented by: @dyemanov
> But ticket 395 has less terms (maybe because older version of FB crashed earlier :))
Older FB versions had a smaller stack size.
> But what about cpu overload for ~100% during this evaluation ? Can this be avoided ?
Engine is doing its work - parsing / compiling your query. This work is heavily CPU bound. What are you going to avoid?
Commented by: @livius2
It can be avoided by calculation of stack usage. Maybe for single expression it should be done during prepare time.
Commented by: @dyemanov
> It can be avoided by calculation of stack usage.
It's nearly impossible to calculate (every function call has its own stack consumption which is different across compilers and 32/64-bit builds).
Commented by: @dyemanov
Possible solution could be to replace recursive expression processing with something more clever. But this is not a short-term goal.
Commented by: @pavel-zotov
> Engine is doing its work - parsing / compiling your query. This work is heavily CPU bound. What are you going to avoid?
MS SQL Express 2017 for similar query (with the same number of terms) replies *instantly*:
Msg 8631, Level 17, State 1, Server HOME-AUX\SQLEXPRESS, Line 1 Internal error: Server stack limit has been reached. Please look for potentially deep nesting in your query, and try to simplify it.
PS. Though, i used console utility
osql -S "HOME-AUX\SQLEXPRESS" -E -i D:\test-mssql.sql -o D:\test-mssql.result.txt
-- because their SQL Studio failed when parsing this :-)
