| Summary: | Object reference sequences can leak reference count | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Adam Mitz <mitza> |
| Component: | ORB | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | sm |
| Priority: | P3 | ||
| Version: | 1.6.6 | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 3550, 3548, 3574 | ||
| Attachments: | test case | ||
I think the proper behaviour here is to instead reset the sequence elements by assigning nil object reference references into the elements when the sequence is shrunk. This should release the previous references. I think the initialize range behaviour described should only be required for the creation of fresh buffers - if object reference sequence is similar to the string sequence implementation then I imagine it is using ::allocbuf to create the buffer. The c++ mapping requires that this creates a buffer with values appropriately initialised to ::nil (). If so (and if my suggestion above is implemented) then increasing the length of the sequence up to the maximum will require no re-initialisation. Increasing above the maximum will allocate a new buffer which will be correctly initialised for all values up to the new maximum (== length). Would you agree with this approach Adam ? (In reply to comment #1) > > Would you agree with this approach Adam ? > Sounds good to me. As you've probably noticed I haven't had a chance to add the test to the repo yet. If you get to it first then go ahead. added blocks test seems to be in the repo yet. Adam/Simon, do you have a patch for this? (In reply to comment #4) > test seems to be in the repo yet. The test was added to the repo a long time ago, but I forgot to notify this bugzilla entry: Fri Nov 7 17:57:34 UTC 2008 Adam Mitz <mitza@ociweb.com> * tests/Bug_3481_Regression: Added a test for this bug. > Adam/Simon, do you have a patch for this? I don't have a patch. Simon's Comment #1 (in the first paragraph) describes how to fix it. Mon Jan 19 19:37:24 UTC 2009 Johnny Willemsen <jwillemsen@remedy.nl> * tao/Generic_Sequence_T.h: When the sequence shrinks we release the members that are not available anymore by the user and then reinitialize them again. This solution works but can probably be improved with respect to performance and exception safety. This fixes bugzilla 3481 and 3548. Tue Jan 20 06:18:24 UTC 2009 Johnny Willemsen <jwillemsen@remedy.nl> * tao/Value_Traits_T.h: Deliver dummy release_range to resolve compile errors Mon Jan 19 19:37:24 UTC 2009 Johnny Willemsen <jwillemsen@remedy.nl> * tao/Generic_Sequence_T.h: When the sequence shrinks we release the members that are not available anymore by the user and then reinitialize them again. This solution works but can probably be improved with respect to performance and exception safety. This fixes bugzilla 3481 and 3548. |
Created attachment 1021 [details] test case When an object reference sequence shrinks the "removed" elements reference counts are not immediately decremented. TAO will lazily decrement the reference counts when the sequence itself is destroyed (actually its buffer). The bug happens when a sequence shrinks and then grows again. These elements are now overwritten and the reference count is lost. generic_sequence::length() calls element_traits::initialize_range(), but initialize_range doesn't decrement the existing objects when they are in this "removed but not yet decremented" state. See attached test which uses this IDL: local interface Foo { }; typedef sequence<Foo> FooSeq; I will add this to the svn repository shortly.