All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Rajotte-Julien via lttng-dev <lttng-dev@lists.lttng.org>
To: "zhenyu.ren" <zhenyu.ren@aliyun.com>
Cc: lttng-dev <lttng-dev@lists.lttng.org>
Subject: Re: [lttng-dev]  回复: 回复: shm leak in traced application?
Date: Fri, 25 Feb 2022 09:21:11 -0500	[thread overview]
Message-ID: <20220225142111.GC1861057@x> (raw)
In-Reply-To: <c0e023fd-bd52-4125-9e50-c096167386ff.zhenyu.ren@aliyun.com>

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

  reply	other threads:[~2022-02-25 14:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 14:38 [lttng-dev] shm leak in traced application? zhenyu.ren via lttng-dev
2022-02-23 15:08 ` [lttng-dev] 回复: " zhenyu.ren via lttng-dev
2022-02-25  4:47   ` [lttng-dev] 回复: " zhenyu.ren via lttng-dev
2022-02-25 14:21     ` Jonathan Rajotte-Julien via lttng-dev [this message]
2022-03-08  5:18       ` [lttng-dev] 回复: " zhenyu.ren via lttng-dev
2022-03-08 15:17         ` Mathieu Desnoyers via lttng-dev
2022-03-09  1:29           ` [lttng-dev] 回复: " zhenyu.ren via lttng-dev
2022-03-09 16:37             ` Mathieu Desnoyers via lttng-dev
2022-03-09 17:07               ` Mathieu Desnoyers via lttng-dev
2022-03-10  3:19               ` [lttng-dev] 回复:回复: " zhenyu.ren via lttng-dev
2022-03-10  4:24                 ` [lttng-dev] 回复: " zhenyu.ren via lttng-dev
2022-03-10 14:31                   ` Mathieu Desnoyers via lttng-dev
2022-03-11  2:08                     ` [lttng-dev] 回复:回复: " zhenyu.ren via lttng-dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220225142111.GC1861057@x \
    --to=lttng-dev@lists.lttng.org \
    --cc=jonathan.rajotte-julien@efficios.com \
    --cc=zhenyu.ren@aliyun.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.