Prevent memory crash when building Query Nodes

[desistefanova]

Having a large query with more than 1000 LogicalNodes crashes and kills the process.
For example query like this:

_id == oid(641c02e5a38d34a988a471ab) OR _id == oid(641c02e5a38d34a988a471ac) OR _id == oid(641c02e5a38d34a988a471ad) OR _id == oid(641c02e5a38d34a988a471ae) OR _id == oid(641c02e5a38d34a988a471af) OR _id == oid(641c02e5a38d34a988a471b0).....

Set limit of QueryNodes depth in the LogicalNode recursion in driver.hpp.
Added MAX_DEPTH_OF_LOGICAL_NODES=1000.

☑️ ToDos

• 📝 Changelog update
• 🚦 Tests (or not relevant)
• C-API, if public C++ API changed.

[jedelbo]

"obj" -> "oid"

[desistefanova]

Good catch!

[nielsenko]

I don't think we should try to fix the issue with a max depth. We don't know that 1000 nodes will be a small enough on all machines at any given time?

Also, this is hardly the only place we can hit a stack overflow. If we want to improve here we should look into SEH (Structured Exception Handling) on Windows, and maybe something like libsigsegv for gcc

[desistefanova]

I don't think we should try to fix the issue with a max depth. We don't know that 1000 nodes will be a small enough on all machines at any given time?

Also, this is hardly the only place we can hit a stack overflow. If we want to improve here we should look into SEH (Structured Exception Handling) on Windows, and maybe something like libsigsegv for gcc

I agree that the max depth can not be predicted. It would be better if this code could be rewritten without recursion.

[nicola-cab]

@ironage PR does that. It is unlikely that we won't be able to cope with a very long list of conditions without recursion.

[jedelbo]

I don't think we should merge this PR now that we have the fix done by @ironage

[desistefanova]

I don't think we should merge this PR now that we have the fix done by @ironage

Which is the @ironage PR that fixes that? I would like to link it here, before to close this PR.

[ironage]

@desistefanova it is #6444
Thanks for bringing this issue to our attention!

[desistefanova]

Handled in #6444