Re: [Libreoffice] UNO Object Life Cycle question

Hi Stephan

Stephan Bergmann <sbergman@redhat.com> writes:
> No, the sending side increments its ref count multiple times for a
> given tuple it sends, unless it earlier received that tuple from the
> other side (i.e., it is "bridged in" at this side), in which case it
> does not increment the ref count at all.

great explanation, thank you!

> > Is there a mechanism that when a link between the server and client
> > bridge breaks, the server releases the resources properly, or do we
> > get/expect memory leaks?
>
> In some sense this is a QoI issue.

What is "a QoI issue"?  Quality of Information?  You mean that the
server must be able to detect disconnection, which works with sockets
but wouldn't work for example with named pipes?

> But existing URP endpoints (binary and Java) do note if a connection
> is broken and locally release the objects they have bridged out across
> that connection.  [snip] (With the above said, just lowering a
> connection without releasing references before should actually also
> happen to work, even if it is not good style to defer release messages
> unduly.)

OK, this is what I was after.

My use case is as follows:

1) connect to LO via unix domain socket

2) load and traverse (via uno) a large word document (about 1200 pages
   of plain text)

3) close the connection

And repeat many times with long running LO process.

During one iteration, i get LO memory usage increase of about 70MB and
on closing the connection it drops back to about the same level no
matter if I use reference counting (release) or not (this confirms what
you said above).

However, in both cases, the memory usage gradually grows a bit with the
number of iterations.  It looks to me as there is a memory leak in LO
not cleaning after the disconnected client properly.

Memory usage without reference counting:

|    | virt | res | shr |
|----+------+-----+-----|
|  1 |  123 |  43 |  28 |
|  2 |  268 | 141 |  52 |
|  3 |  288 | 161 |  52 |
|  4 |  275 | 148 |  52 |
|  5 |  326 | 198 |  52 |
|  6 |  274 | 147 |  52 |
|  7 |  272 | 145 |  52 |
|  8 |  287 | 159 |  52 |
|  9 |  285 | 158 |  52 |
| 10 |  273 | 146 |  52 |
| 11 |  278 | 151 |  52 |
| 12 |  339 | 212 |  52 |
| 13 |  281 | 154 |  52 |
| 23 |  327 | 199 |  52 |
| 24 |  324 | 196 |  52 |
| 25 |  323 | 196 |  52 |
| 26 |  323 | 196 |  52 |
| 36 |  327 | 199 |  52 |
| 37 |  325 | 197 |  52 |
| 38 |  325 | 197 |  52 |
| 48 |  328 | 200 |  52 |
| 49 |  328 | 200 |  52 |
| 59 |  330 | 187 |  36 |
| 60 |  327 | 184 |  36 |
| 61 |  328 | 185 |  36 |
| 62 |  326 | 183 |  36 |
| 63 |  328 | 185 |  36 |

Memory usage with reference counting:

|      | virt | res | shr |
|------+------+-----+-----|
|    1 |  123 |  43 |  28 |
|    2 |  269 | 141 |  52 |
|    3 |  286 | 158 |  52 |
|    4 |  293 | 165 |  52 |
|    5 |  300 | 172 |  52 |
|    6 |  295 | 168 |  52 |
|    7 |  302 | 174 |  52 |
|    8 |  317 | 189 |  52 |
|    9 |  334 | 206 |  52 |
|   10 |  332 | 204 |  52 |
|   11 |  323 | 195 |  52 |
|   12 |  322 | 194 |  52 |
|   13 |  302 | 174 |  52 |
|   14 |  299 | 171 |  52 |
|   15 |  306 | 179 |  52 |
|   16 |  300 | 172 |  52 |
|  736 |  372 | 184 | 6.4 |
|  737 |  372 | 204 |  16 |
|  738 |  372 | 204 |  16 |
|  739 |  372 | 203 |  16 |
|  740 |  371 | 203 |  16 |
|  741 |  372 | 203 |  16 |
|  742 |  372 | 203 |  16 |
|  752 |  372 | 205 |  16 |
|  753 |  372 | 204 |  16 |
|  754 |  372 | 204 |  16 |
|  764 |  371 | 204 |  16 |
|  774 |  373 | 207 |  16 |
|  784 |  372 | 206 |  16 |
|  785 |  373 | 206 |  16 |
|  795 |  373 | 207 |  16 |
|  805 |  372 | 206 |  16 |
|  955 |  374 | 171 | 1.1 |
|  965 |  375 | 201 |  16 |
|  975 |  375 | 201 |  16 |
|  985 |  375 | 202 |  16 |
|  995 |  375 | 200 |  16 |
| 1015 |  376 | 196 |  16 |
| 1035 |  376 | 187 |  16 |
| 1055 |  377 | 188 |  16 |
| 1155 |  377 | 147 | 0.6 |
| 1165 |  376 | 175 |  16 |

The memory usage keeps growing, slightly but persistently.  Is it a
leak, or a feature of the custom LO allocator, or would it stabilise
eventually?

Also, according to what you said above, it should not matter whether the
client implements reference counting at all.  The leak seems smaller
with reference counting in place.  However, it does not disappear.

Thank you,

Tomas