Beginning in v9.7 fixpack 5, a memory leak is possible for all
LOB fields of local row variables that are associated with the
top-level row descriptor. Basically, this means any LOB field
of a local row variable which is not part of a nested type
object. The leak will occur on every invocation of the routine.
The amount of the leakage will depend on the size of the data
assigned to each LOB row field. LOB fields of row parameters do
not leak.
Here is an example:
create type row_A as row(F1 integer, F2 varchar(10), F3
clob(32K)) %
create type row_B as row(F1 row_A, F2 clob(32K)) %
create procedure test
begin
declare A row_A;
declare B row_B;
-- ...
end %
`A` and `B` are both local row variables. The PVM "owns" the
row descriptor for each: a `row_A` descriptor for `A`, and a
`row_B` descriptor for `B`. This is the "top-level" object
which is the subject of this defect.
Additionally, `B` is a nested type object that contains a field
of type `row_A`. It therefore contains two LOB objects: `B.F2`
and `B.F1.F3`. However, only `B.F2` is directly associated with
the top-level row descriptor; the rest is nested type data that
is dynamically managed by the run-time.
The essence of the defect is that the PVM is not freeing storage
associated with LOB fields in any row type descriptor that it
owns directly. In this example, that means `A.F3` and `B.F2`.
Neither of these LOB fields will be freed by the PVM and will
therefore leak.
The LOB field `B.F1.F3` is part of the dynamic data managed for
the nested type object. Storage allocated for this LOB field
*will* be freed properly. |
