Lots of duplicate StackFrames during Checkin

[muren400]

Hi,

we have various IFC files created in Card/1 that repeatedly crashed our bimserver on checkin.

It seems like while traversing the ObjectPlacement query, QueryIncludeStackFrames for the same buildingstoreys are created again and again.

You can reproduce the behavior by importing this file.
I extracted a single Element from the original Model using BimPlusPlus.

For that example the server throws this exception:

'org.bimserver.BimserverDatabaseException: Query stack size > 10000000, probably a bug, please report

But we also had cases where the stack just grew until the bimserver froze completely. Maybe thats dependent on the model size and the amount of render engine processes?

One way this could be fixed is to remove this line from BimServer.java.

BIMserver/BimServer/src/org/bimserver/BimServer.java

Lines 749 to 750 in b27aa20

	// The sole reason is to make sure this is done once, and then cached
	objectPlacement.makeDirectRecursive(new HashSet<>());

But I'm pretty sure the fields where converted to direct fields for performance reasons?

Another way I found was to skip calling DatabaseReadingStackFrame.processPossibleIncludes() for objects that were already present in the cache. I could submit a pull request for that if you want me to.

Thanks,
BA

[hlg]

Interesting catch, thank you for reporting and providing such concise sample. I think the issue is with DatabaseReadingStackFrame indeed, but has nothing to do with the cache. It does processes the includes directly plus it pushes a QueryIncludeStackFrame to the stack processing queue, which in turn triggers processing of the same includes. In your example case this leads to deep recursion and an exponentially growing stack.

Also the setting of the direct fields seems to be done twice which is unnecessary but does not hurt as much.

I'll prepare a preliminary fix which keeps the QueryIncludeStackFrame and removes the direct processing of includes. Then, only FollowReferenceStackFrame is then skipped and processed directly for "direct" fields . After that I have to figure out whether it was the intention to also to remove the QueryIncludeStackFrame and if so how to properly implement this.

I think with this, we finally have the reason for #1230 which seems to be the same issue actually.