<div dir="ltr">After digging some past bug reports on D-Bus, I found the following one:<div><br></div><div><a class="gmail-sc-cpmKsF gmail-IVnFo" href="https://gitlab.freedesktop.org/dbus/dbus/-/issues/105" title="https://gitlab.freedesktop.org/dbus/dbus/-/issues/105" style="color:rgb(0,101,255);outline:0px;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px;letter-spacing:-0.07px;white-space:pre-wrap">https://gitlab.freedesktop.org/dbus/dbus/-/issues/105</a> </div><div><br></div><div>It mentioned that D-Bus never freed its data.</div><div><br></div><div>D-Bus authors, please advise whether the above statement  is true. If it is not, please advise how to free D-Bus daemon data holdup?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 4:17 PM Hailun Tan <<a href="mailto:dearambermini@gmail.com">dearambermini@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I am currently trying  the D-Bus sample codes from the following link:<div><br></div><div><a href="https://linoxide.com/how-tos/d-bus-ipc-mechanism-linux/" target="_blank">https://linoxide.com/how-tos/d-bus-ipc-mechanism-linux/</a>  <br></div><div><br></div><div>It  worked.</div><div><br></div><div>Then I performed the exhaustion tests on the sample code above i.e., broadcast the DBus messages rapidly to other DBus users, who did not handle the received message as quick as the sender sent them, the D-Bus daemon's virtual memory usage started to grow, which  is expected as DBus daemon's outgoing queue accumulated.<br></div><div><br></div><div>Then I stopped the sender process, the D-Bus daemon's virtual memory usage should start to shrink as the receiver is disseminating the message with the filter function. However, the D-Bus daemon's virtual memory usage did not shrink down even after the receiver process completed disseminating all the data. </div><div><br></div><div>I have tried the above tests for  the following three cases:</div><div><br></div><div>1. sender application broadcasted the messages to all receiver applications via DBus.</div><div>2. sender application sent the method call messages to a particular receiver application, without requesting a reply</div><div>3. 

sender application sent the method call messages to a particular receiver application, requesting a reply from receiver application.</div><div><br></div><div>case 1 and 2 will make the dbus daemon virtual memory usage enlarge and its virtual memory usage would not shrink if the sender application were terminated and the receiver application completed the handlings of all messages from sender.</div><div><br></div><div>Case 3, however, would not have the DBus daemon VM usage grown. The VM usage remained unchanged during the test.</div><div><br></div><div>So my question is, how to make the case 1 and 2 behave as case 3? Or alternatively,  even though the VM usage grew due to the message queues in DBus daemon,  its VM usage should shrink down to its original state when the system was up? </div><div><br></div><div>I doubted that DBus daemon should have some configurations to set so that it can release these memory usage after the receiver application completed handling these messages. I have spent quite a while looking for such a configuration in the DBus daemon config file (for session bus) in the following link:</div><div><br></div><div><a href="https://dbus.freedesktop.org/doc/dbus-daemon.1.html" target="_blank">https://dbus.freedesktop.org/doc/dbus-daemon.1.html</a> </div><div><br></div><div>But I cannot find  any. So Please advise how I can make dbus daemon to release these VM usages after the messages have been handled?<br></div></div>
</blockquote></div>