Issue Details (XML | Word | Printable)

Key: CORE-6223
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Pavel Zotov
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

FB crashes when evaluating too long expression

Created: 12/Jan/20 07:37 AM   Updated: 12/Jan/20 11:21 AM
Component/s: Engine
Affects Version/s: 3.0.4, 4.0 Beta 1
Fix Version/s: None

File Attachments: 1. File eval-too-long-expr-leads-fb-to-crash.7z (0.4 kB)

Issue Links:
Duplicate
 

QA Status: No test


 Description  « Hide
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)



 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Pavel Zotov added a comment - 12/Jan/20 07:40 AM
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.


Dmitry Yemanov added a comment - 12/Jan/20 07:43 AM
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).

Dmitry Yemanov added a comment - 12/Jan/20 07:44 AM
Duplicate for CORE-395?

Pavel Zotov added a comment - 12/Jan/20 07:52 AM
> Duplicate for CORE-395?

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




Pavel Zotov added a comment - 12/Jan/20 07:53 AM
> 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 ?

Dmitry Yemanov added a comment - 12/Jan/20 08:02 AM
> 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?

Karol Bieniaszewski added a comment - 12/Jan/20 08:39 AM
It can be avoided by calculation of stack usage. Maybe for single expression it should be done during prepare time.

Dmitry Yemanov added a comment - 12/Jan/20 09:04 AM - edited
> 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).

Dmitry Yemanov added a comment - 12/Jan/20 09:05 AM
Possible solution could be to replace recursive expression processing with something more clever. But this is not a short-term goal.

Pavel Zotov added a comment - 12/Jan/20 11:21 AM
> 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 :-)