Bug #9996
Object references should be decremented at the nearest block instead of the top-level block
100%
History
#2 Updated by Dănuț Filimon about 1 year ago
- % Done changed from 0 to 90
- Status changed from New to WIP
- Assignee set to Dănuț Filimon
The problem was discussed in #9538-153 - #9538-158, the problem is that we increase the reference of an object when we assign it, but also when the function assigns the return value and this can cause multiple references to be kept longer until the top-level block is executed. The solution is to decrement the reference at the nearest block.
The fix is available in 9538d, it was reviewed but during testing I found an issue (#9538-167) which takes a while to reproduce.
#3 Updated by Dănuț Filimon about 1 year ago
- With 7156e/15755, there are 7247 increment and decrement calls for the problematic object.
- With 7156e/15755 + 9538d, there are 7249 increment and decrement calls for the problematic object.
The answer should lie into the additional 4 calls, currently investigating.
#4 Updated by Dănuț Filimon about 1 year ago
Dănuț Filimon wrote:
I focused on finding out the test suite and ran a few tests with and without 9538d on the problematic module:I managed to find the problematic test suite by comparing the two results, the test suite only has 11 tests and I am able to reproduce the issue much faster now :). In this scenario I tested:
- With 7156e/15755, there are 7247 increment and decrement calls for the problematic object.
- With 7156e/15755 + 9538d, there are 7249 increment and decrement calls for the problematic object.
The answer should lie into the additional 4 calls, currently investigating.
- With 7156e/15755, there are 105 increment and decrement calls for the problematic object.
- With 7156e/15755 + 9538d, there are 105 increment and decrement calls for the problematic object. 71 of the decrement calls in
ObjectOps$WorkArea.scopeFinished()are resulted frominternalDefinitions. The problem lies in a DECREMENT call that is called at the end of the test, while it should be called much earlier. There is also an error in this suite that might contribute to this scenario.
#5 Updated by Dănuț Filimon about 1 year ago
- Status changed from WIP to Review
- % Done changed from 90 to 100
- reviewer Constantin Asofiei added
The issue was that I was introducing the internal definitions in an external procedure, when it already has extProgDefinitions. I fixed this issue in 9538d/15910.
Constantin, please review.
#6 Updated by Constantin Asofiei about 1 year ago
- now we register ObjectOps as 'block-scopeable' instead of 'top-level scopeable'.
- this means that in
ObjectOps.scopeStartandObjectOps.scopeFinished, all code which is not (yet) in a 'is this a top-level block' condition, must be moved into one. The only thing that is done for all blocks is theinternalDefinitionsmanagement - the change for
EXTERNAL_PROC- I don't understand this one. Can you please explain it a little?
#7 Updated by Dănuț Filimon about 1 year ago
- Status changed from Review to WIP
- % Done changed from 100 to 90
Constantin Asofiei wrote:
Danut, some notes:
- now we register ObjectOps as 'block-scopeable' instead of 'top-level scopeable'.
- this means that in
ObjectOps.scopeStartandObjectOps.scopeFinished, all code which is not (yet) in a 'is this a top-level block' condition, must be moved into one. The only thing that is done for all blocks is theinternalDefinitionsmanagement
Ooh, you are right. So I'd have to make sure that I do not clear the objects in blocks that are not top-level (and the rest of the code that is not related to the internal definitions). I'll fix that.
- the change for
EXTERNAL_PROC- I don't understand this one. Can you please explain it a little?
The problem was that when running unit tests we would push an external procedure in UnitTestServer and any objects defined in an internal procedure (the executed test) would be registered in the internal definitions and when the test finished we didn't have any open buffers, thus the stack trace from #9538-167. I came to the conclusion that we have definitions which should have been registered in the external definitions collection which ended up in the internal definitions collection and corrected that.
#8 Updated by Dănuț Filimon about 1 year ago
- % Done changed from 90 to 100
- Status changed from WIP to Review
I committed 9538d/15911, now scopeStart and scopeFinished will handle internalDefinitions for all blocks and the rest of the code will only be executed for top level blocks.
Constantin, please review.
#9 Updated by Constantin Asofiei about 1 year ago
- Status changed from Review to Internal Test
Dănuț Filimon wrote:
Constantin, please review.
I'm OK with the changes.
I think we need rebase and after that it can go into testing.
#10 Updated by Dănuț Filimon about 1 year ago
I rebased 9538d to latest trunk/15960, the branch is now at revision 15965.
I will create a test plan and email everyone involved.
#11 Updated by Dănuț Filimon about 1 year ago
I rebased 9538d to latest trunk/15980, the branch is now at revision 15985.
#12 Updated by Dănuț Filimon about 1 year ago
9538d passed all regression tests and can be merged.
#13 Updated by Constantin Asofiei about 1 year ago
- Status changed from Internal Test to Merge Pending
9538d can be merged now.
#14 Updated by Dănuț Filimon about 1 year ago
- Status changed from Merge Pending to Test
- version_resolved set to trunk/15998
Branch 9538d was merged to trunk revision 15998 and archived.