Hi zhenyu.ren, Please open a bug on our bug tracker and provide a reproducer against the latest stable version (2.13.x).
https://bugs.lttng.org/ Please follow the guidelines: https://bugs.lttng.org/#Bug-reporting-guidelines Cheers On Fri, Feb 25, 2022 at 12:47:34PM +0800, zhenyu.ren via lttng-dev wrote: > Hi, lttng-dev team > When lttng-sessiond exits, the ust applications should call > lttng_ust_objd_table_owner_cleanup() and clean up all shm resource(unmap and > close). Howerver I do find that the ust applications keep opening "all" of > the shm fds("/dev/shm/ust-shm-consumer-81132 (deleted)") and do NOT free shm. > If we run lttng-sessiond again, ust applications can get a new piece of > shm and a new list of shm fds so double shm usages. Then if we kill > lttng-sessiond, what the mostlikely happened is ust applications close the > new list of shm fds and free new shm resource but keeping old shm still. In > other word, we can not free this piece of shm unless we killing ust > applications!!! > So Is there any possilbe that ust applications failed calling > lttng_ust_objd_table_owner_cleanup()? Do you have ever see this problem? Do > you have any advice to free the shm without killling ust applications(I tried > to dig into kernel shm_open and /dev/shm, but not found any ideas)? > > Thanks in advance > zhenyu.ren > > > > ------------------------------------------------------------------ > 发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org> > 发送时间：2022年2月23日(星期三) 23:09 > 收件人：lttng-dev <lttng-dev@lists.lttng.org> > 主 题：[lttng-dev] 回复： shm leak in traced application? > > >"I found these items also exist in a traced application which is a long-time > >running daemon" > Even if lttng-sessiond has been killed!! > > Thanks > zhenyu.ren > ------------------------------------------------------------------ > 发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org> > 发送时间：2022年2月23日(星期三) 22:44 > 收件人：lttng-dev <lttng-dev@lists.lttng.org> > 主 题：[lttng-dev] shm leak in traced application? > > Hi, > There are many items such as "/dev/shm/ust-shm-consumer-81132 (deleted)" > exist in lttng-sessiond fd spaces. I know it is the result of shm_open() and > shm_unlnik() in create_posix_shm(). > However, today, I found these items also exist in a traced application > which is a long-time running daemon. The most important thing I found is that > there seems no reliable way to release share memory. > I tried to kill lttng-sessiond but not always release share memory. > Sometimes I need to kill the traced application to free share memory....But > it is not a good idea to kill these applications. > My questions are: > 1. Is there any way to release share memory without killing any traced > application? > 2. Is it normal that many items such as "/dev/shm/ust-shm-consumer-81132 > (deleted)" exist in the traced application? > > Thanks > zhenyu.ren > > > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Jonathan Rajotte-Julien EfficiOS _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
