Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FB crashes when evaluating too long expression [CORE6223] #6467

Open
firebird-automations opened this issue Jan 12, 2020 · 12 comments
Open

FB crashes when evaluating too long expression [CORE6223] #6467

firebird-automations opened this issue Jan 12, 2020 · 12 comments

Comments

@firebird-automations
Copy link
Collaborator

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
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Commented by: @dyemanov

Duplicate for CORE395?

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue duplicates CORE395 [ CORE395 ]

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant