Hi Stephan Stephan Bergmann <sberg...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
