FB crashes when evaluating too long expression [CORE6223]

[firebird-automations]

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)

[firebird-automations]

Modified by: @pavel-zotov

Attachment: eval-too-long-expr-leads-fb-to-crash.7z [ 13413 ]

[firebird-automations]

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.

[firebird-automations]

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).

[firebird-automations]

Commented by: @dyemanov

Duplicate for CORE395?

[firebird-automations]

Commented by: @pavel-zotov

> Duplicate for CORE395?

Yes, exactly. But ticket 395 has less terms (maybe because older version of FB crashed earlier :))

[firebird-automations]

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 ?

[firebird-automations]

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?

[firebird-automations]

Modified by: @dyemanov

Link: This issue duplicates CORE395 [ CORE395 ]

[firebird-automations]

Commented by: @livius2

It can be avoided by calculation of stack usage. Maybe for single expression it should be done during prepare time.

[firebird-automations]

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).

[firebird-automations]

Commented by: @dyemanov

Possible solution could be to replace recursive expression processing with something more clever. But this is not a short-term goal.

[firebird-automations]

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 :-)