Repository navigation
Lots of duplicate StackFrames during Checkin #1342
Description
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
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
Activity
hlg commentedon Dec 13, 2024
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.
preliminary fix for #1342, remove redundant query code
Merge PR #1342