EMCustomのメモリリークについて

[w. ito]

お世話になっております。

https://groups.google.com/a/edgematrix.com/g/edgematrixstreamtoolkit/c/N9_WB-n8keE
URLのQAにあるメモリリークについて、弊社で作成したEAPでもメモリリークが発生しており
QAにしたがってチュートリアルのサンプルコードにあるJson Builderを使用した実装に修正したのですが改善が見られませんでした。
問題切り分けのために添付のソースコードにあるよう、jsonを固定値で実装し
34行目の　*out_meta = json_to_string ( output_node, TRUE );
のみをコメントアウトして比較したところ、コメントアウトした場合にメモリリークが改善されました。
EAP内でcallbackを使用しているため*out_metaへの代入は必須と考えているのですが、
上記コメントアウト以外でメモリリーク改善のためにできることはありますでしょうか。

メモリの計測方法はEAPをCLI実行し、その間「watch -d 'ps auxf | grep gstd | tee -a ./runcli.log'」コマンドでgstdプロセスのメモリ消費量の推移を取得しています。
メモリの推移も添付いたします。

お手数おかけしますが、確認のほどよろしくお願いいたします。

[ts...@edgematrix.com]

お世話になっております。

現在どのようなケースでEMCustomのリークが発生するのか確認しておりますので、

アップデートがありましたら連絡させていただきます。

2023年3月31日金曜日 9:42:51 UTC+9 w. ito:

[w. ito]

確認ありがとうございます。

こちら調査中とのこと、承知いたしました。
お手数おかけしますが、引き続きよろしくお願いいたします。

2023年3月31日金曜日 9:54:04 UTC+9 ts...@edgematrix.com:

[ts...@edgematrix.com]

お世話になっております。

以下で連絡した通り、fixの準備ができましたが、

早めにこちらで動作確認されますか？

https://groups.google.com/a/edgematrix.com/g/edgematrixstreamtoolkit/c/N9_WB-n8keE/m/4NI_xawTCgAJ

2023年3月31日金曜日 11:16:57 UTC+9 w. ito:

[w. ito]

お世話になっております。

修正対応ならびにご案内ありがとうございます。
ベータ版へのアクセス権限いただけますと幸いです。
また、こちらでご案内いただいたベータ版にアップデートした場合、後方互換性などは担保されていますでしょうか。

以上、よろしくお願いいたします。

2023年4月4日火曜日 19:26:31 UTC+9 ts...@edgematrix.com:

[ts...@edgematrix.com]

それでは準備出来次第ご案内しますので、しばらくお待ちください。

> また、こちらでご案内いただいたベータ版にアップデートした場合、後方互換性などは担保されていますでしょうか。

後方互換性は維持されるようにしていますが、

各アプリの詳細までは把握できない部分があるため、今後はこのような方法で、

リリース前に最終確認をしたいと思います。

なお、次期バージョンとなるv2.5は、

前回のようにパイプラインのプラグインの入れ替えのような大きな変更はなく、

主にエッジビュー関連のStream（例えば利用帯域に応じてストリーミングを最適化するアルゴリズムなど）とサービスの変更が主なものです。

2023年4月5日水曜日 15:00:20 UTC+9 w. ito:

[ts...@edgematrix.com]

こちらに案内を出しましたので、ご確認ください。

https://groups.google.com/a/edgematrix.com/g/edgematrixstreamtoolkit/c/rpRocQMCghM/m/qa4g5JTWBQAJ

2023年4月6日木曜日 9:03:11 UTC+9 ts...@edgematrix.com:

[w. ito]

案内ありがとうございます。
確認してアップデート検証してみます。

2023年4月10日月曜日 11:58:10 UTC+9 ts...@edgematrix.com:

[w. ito]

お世話になっております。

上記で質問させていただきましたメモリリークですが、v2.5にアップデート後も改善されていないように見えます。
以下に検証方法と結果を記しますので、検証方法がこれで問題ないか、問題ない場合メモリリークの対策は何かないかを教えていただけますと幸いです。

・検証方法

　v2.5にアップデート後、EMCustomを再ビルドしアプリを作成
　toolkitboxにてgstdからCLIでアプリを起動
　その後「watch -d 'ps auxf | grep gstd | tee -a ./runcli.log'」でgstdプロセスをログに掃き出し、RSS部分をチェック
　検証用ソース（添付のemcustom_post_process.c）の58行目「*out_meta = json_to_string ( output_node, TRUE );」をコメントアウトした場合としなかった場合でメモリ使用量の差を検証しました
　なお、検証用ソースはチュートリアルにあるJsonBuilderのサンプルソースをほとんど流用したものとなっています。
　https://edgestreamsdk-tutorial.readthedocs.io/en/latest/emcustom.html?highlight=JsonBuilder#how-to-add-a-custom-library

・検証結果
　検証結果を添付画像（メモリ推移v2.5.PNG）に記します。縦軸がps auxfコマンドで確認したRSS[byte]、横軸は実行時間[mm:ss]です。
　添付画像にあるように、out_metaへの代入をコメントアウトしなかった場合はメモリ量が増加しているのに対して、コメントアウトした場合はほとんど増加しません。
　out_meta代入部分でメモリリークが起きていると思われるのですが、

　psコマンドによるgstdプロセス監視の検証方法が合っているかなど含めてご回答いただけますと幸いです。

以上、お手数おかけしますがなにとぞご確認の程よろしくお願いいたします。

2023年4月11日(火) 15:59 w. ito <wataru3...@gmail.com>:

[Takenori Sato]

お世話になっております。

EAPをCLIで実行し、gstdのRSS部分をモニタリングされたとのことで、

確認方法としては問題ありません。

まず念の為バージョンをご確認いただきたいのですが、

emcustomは以下のように、0.6.3-2にアップデートされているでしょうか？

$ apt policy libgstemcustom

libgstemcustom:

  Installed: 0.6.3-2

  Candidate: 0.6.3-2

  Version table:

 *** 0.6.3-2 500

        500 https://apt.console.staging.edgematrix.net/airbase/apt/debian r32.4/main arm64 Packages

        100 /var/lib/dpkg/status

2023年4月25日(火) 11:25 w. ito <wataru3...@gmail.com>:

[ts...@edgematrix.com]

> 検証結果を添付画像（メモリ推移v2.5.PNG）に記します

こちらを確認しておりませんでしたが、パイプライン開始後５分〜１０分ぐらいメモリ増が見られるのは、正常です。

もし増加し続けるようであればリークですが、そうでなければ各種バッファリング（GLIBのメモリ管理含む）の影響です。

また、いただいたカスタムコードで、v2.5環境で以下の通り実行してみました。

gst-launch-1.0 uridecodebin3 uri="RTSP_URL" ! queue  ! \
nvstreammux0.sink_0 nvstreammux name=nvstreammux0 batch-size=1 batched-push-timeout=40000 width=1280 height=720 live-source=TRUE ! queue ! nvvideoconvert ! queue ! \
nvinfer config-file-path="/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_infer_primary.txt" ! queue ! nvvideoconvert ! \
emcustom custom-lib=PATH_TO_YOUR_LIBRARY  ! fakesink

最初の10分で2MB増加しましたが、その後の20分は1MB増加となり、特に顕著な増加傾向は見られませんでした。

2023年4月25日火曜日 16:07:13 UTC+9 ts...@edgematrix.com:

[w. ito]

回答いただきありがとうございます。

emcustomのverですが、確認したところ下記のようにInstalledが0.6.3-1となっており微妙に結果が違うのですがこれは0.6.3-2にアップデートできているのでしょうか。

nvidia@nvidia-desktop:~$ apt policy libgstemcustom libgstemcustom: Installed: 0.6.3-1 Candidate: 0.6.3-2 Version table: 0.6.3-2 500 500 https://apt.console.edgematrix.com/airbase/apt/debian poc/main arm64 Packages *** 0.6.3-1 100 100 /var/lib/dpkg/status

2023年4月25日火曜日 17:12:10 UTC+9 ts...@edgematrix.com:

[w. ito]

連投失礼いたします。

パイプライン開始後５分〜１０分ぐらいメモリ増が見られるのは、正常です。

５〜１０分間はメモリ増は正常な仕様とのこと、承知いたしました。
すみません、当方の検証では５分程度しか動作させておりませんでしたので、３０分〜１時間程度動作させてみてメモリ量を観測してみたいと思います。
検証結果が出ましたら、結果をこちらにてご連絡させていただきます。

 また、いただいたカスタムコードで、v2.5環境で以下の通り実行してみました。

gst-launch-1.0 uridecodebin3 uri="RTSP_URL" ! queue  ! \
nvstreammux0.sink_0 nvstreammux name=nvstreammux0 batch-size=1 batched-push-timeout=40000 width=1280 height=720 live-source=TRUE ! queue ! nvvideoconvert ! queue ! \
nvinfer config-file-path="/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_infer_primary.txt" ! queue ! nvvideoconvert ! \
emcustom custom-lib=PATH_TO_YOUR_LIBRARY  ! fakesink 

検証ありがとうございます。
最初の１０分以降は特に顕著な増加傾向が見られなかったとのことで、参考にさせていただきます。

2023年4月25日(火) 17:12 ts...@edgematrix.com <ts...@edgematrix.com>:

[ts...@edgematrix.com]

> emcustomのverですが、確認したところ下記のようにInstalledが0.6.3-1となっており微妙に結果が違うのですがこれは0.6.3-2にアップデートできているのでしょうか。

いえ、これはアップデートできておりません。

$ apt policy libgstemcustom

libgstemcustom:

  Installed: 0.6.3-2

  Candidate: 0.6.3-2

  Version table:

 *** 0.6.3-2 500

        500 https://apt.console.staging.edgematrix.net/airbase/apt/debian r32.4/main arm64 Packages

        100 /var/lib/dpkg/status

出力を見ると、上記の通りr32.4となっておりますので、

これはベータ環境ではなく、v2.4安定版の環境のままとなっています。

2023年4月26日水曜日 12:41:06 UTC+9 w. ito:

[ts...@edgematrix.com]

> 出力を見ると、上記の通りr32.4となっておりますので、

> これはベータ環境ではなく、v2.4安定版の環境のままとなっています。

失礼しました。アップデートできていないのに変わりはありませんが、ベータ環境にはなっていました。

nvidia@nvidia-desktop:~$ apt policy libgstemcustom libgstemcustom: Installed: 0.6.3-1 Candidate: 0.6.3-2 Version table: 0.6.3-2 500 500 https://apt.console.edgematrix.com/airbase/apt/debian poc/main arm64 Packages *** 0.6.3-1 100 100 /var/lib/dpkg/status

2023年4月26日水曜日 15:04:07 UTC+9 ts...@edgematrix.com:

[ts...@edgematrix.com]

v2.5へのアップデート手順のうち、以下のコマンドは実施されたか、改めてご確認ください。

$ TOOLKIT_HOME/bin/update_toolkit.sh

もし実施してもアップデートできない場合は、上記コマンド実行出力結果を教えてください。

2023年4月26日水曜日 15:05:41 UTC+9 ts...@edgematrix.com:

[w. ito]

お世話になっております。

update_toolkit.shを再度実行してみましたが変わりないように見えます。
コマンドの出力結果を添付しますので、お手数ですがご確認いただけますと幸いです。

2023年4月26日(水) 15:10 ts...@edgematrix.com <ts...@edgematrix.com>:

[ts...@edgematrix.com]

ご確認ありがとうございます。

２点ご確認をお願いします。

> /mnt/nvme/toolkit_home/bin/update_toolkit.sh: line 34: ./check_emi_maintenance.sh: No such file or directory

TOOLKIT_HOME/binから実行すれば上記エラーは出ずにスクリプトが実行されますので、再度実行してみてください。

その後、もしまだアップデートできない場合は、edgeamtrix-streamのインストール状況の確認をお願いします。

$ apt policy edgematrix-stream

2023年4月26日水曜日 17:04:05 UTC+9 w. ito:

[w. ito]

お世話になっております。

TOOLKIT_HOME/binから実行すれば上記エラーは出ずにスクリプトが実行されますので、再度実行してみてください。

失礼しました。カレントディレクトリがホームディレクトリの状態で実行しておりました。

TOOLKIT_HOMEが環境変数に設定されておらず、/mnt/nvme/toolkit_home/binがカレントディレクトリの状態で再度実行しましたが手順合っていますでしょうか。

再度update_toolkit.shを実行してみましたが変わらず「Installed: 0.6.3-1」でした。

$ apt policy edgematrix-stream

の実行結果は添付のログにもありますが以下のようになりました。こちらは問題ありますでしょうか。

nvidia@nvidia-desktop:~$ apt show python3-edgematrix-stream-toolkit
Package: python3-edgematrix-stream-toolkit
Version: 2.5.0b0-1
Priority: optional
Section: python
Source: edgematrix-stream-toolkit
Maintainer: Takenori Sato <ts...@edgematrix.com>
Installed-Size: 313 kB
Depends: python3-boto3, python3-gpg, python3-pycryptodome, python3-pysnmp4, python3-requests, python3:any (>= 3.3.2-2~), edgematrix-stream (>= 2.12.1), edgematrix-stream (<< 3.0), python3-emisecurity (>= 2.0.3), python3-emitools (>= 2.3.2), meson, python3-libnvinfer-dev, uff-converter-tf
Download-Size: 41.7 kB
APT-Manual-Installed: yes
APT-Sources: https://apt.console.edgematrix.com/airbase/apt/debian poc/main arm64 Packages
Description: EDGEMATRIX Stream Toolkit allows an AI model developer to build, test, and package an EAP (EDGEMATRIX Stream Application Package).

以上、よろしくお願いいたします。

2023年4月26日(水) 17:37 ts...@edgematrix.com <ts...@edgematrix.com>:

[Takenori Sato]

お手数をおかけしております。

> $ apt policy edgematrix-stream

> の実行結果は添付のログにもありますが以下のようになりました。こちらは問題ありますでしょうか。

ややこしくて申し訳ございませんが、

python3からは始まるtoolkitの方ではなくて、

EDGEMATRIX Stream本体の方になります。

こちらが、gstemcustomへの依存関係を持っています。

Toolkitでは2.12.1以上の依存関係になっており、

poc環境に登録されているのは2.12.1-2で、libgstcustom=0.6.3-2となっていますが、

edgematrix-streamのインストールが失敗しているような状態になっているのかもしれません。

佐藤

2023年4月27日(木) 13:58 w. ito <wataru3...@gmail.com>:

[w. ito]

お世話になっております。

失礼しました。

現状の $ apt policy edgematrix-stream の結果は以下のようになりました。

nvidia@nvidia-desktop:~$ apt policy edgematrix-stream

 edgematrix-stream:

   Installed: 2.12.1-1

   Candidate: 2.12.1-2

   Version table:

      2.12.1-2 500

         500 https://apt.console.edgematrix.com/airbase/apt/debian poc/main arm64 Packages

  *** 2.12.1-1 100

         100 /var/lib/dpkg/status

 nvidia@nvidia-desktop:~$ 

Installed: 2.12.1-1となっていますので、これは佐藤様がおっしゃる通りインストールが失敗している状態でしょうか。

2023年4月27日(木) 16:08 Takenori Sato <ts...@edgematrix.com>:

[Takenori Sato]

ご確認ありがとうございます。

ということは、失敗したのではなく、アナウンス後にすぐ実施いただいていたため、

現在の一つ前のバージョンがインストールされている状態のようです。

Toolkitの依存関係は満たしているため、更新版はインストールされない状態です。

改めて確認したところ、メモリーリークの修正は2.12.1-1（emcustom 0.6.3-1）で入っておりました。

emcustom 0.6.3-2には、

processだとseg faultになる件もご報告いただいておりましたが、その修正と、

empycustomのエラーのパッチが入っています。

もしメモリーリーク対策だけでしたら、このバージョンでも問題ございませんので、

1時間ほど実行した検証結果をお待ちしております。

佐藤

2023年4月27日(木) 16:43 w. ito <wataru3...@gmail.com>:

[w. ito]

確認ありがとうございます。

メモリリークの修正は現状の2.12.1-1（emcustom 0.6.3-1）でもされているとのことで承知いたしました。
このバージョンで引き続き検証したいと思います。

また、30分〜1時間程度の動画でメモリ使用量を確認したのですが
結果としてメモリ使用量が増加しているように見えます。

メモリ使用量のグラフを添付します。

横軸が秒で縦軸がKBなので1時間で700MB程度のメモリ増加量となっており
このまま続くと無視できないメモリ使用量となりそうなのですが原因や対策などありますでしょうか。
検証に使用したソースコードやメモリ量確認方法は以前と変更ありません。

以上、お手数おかけしますがご確認の程よろしくお願いいたします。

2023年4月27日(木) 16:59 Takenori Sato <ts...@edgematrix.com>:

[Takenori Sato]

ご確認ありがとうございます。

> 横軸が秒で縦軸がKBなので1時間で700MB程度のメモリ増加量となっており

毎分10MB以上リークしているので、このカスタムコード由来の何かだと思います。

今週確認してみますので、しばらくお待ちください。

2023年5月8日(月) 14:29 w. ito <wataru3...@gmail.com>:

[ts...@edgematrix.com]

> また、いただいたカスタムコードで、v2.5環境で以下の通り実行してみました。

> 

> gst-launch-1.0 uridecodebin3 uri="RTSP_URL" ! queue  ! \
nvstreammux0.sink_0 nvstreammux name=nvstreammux0 batch-size=1 batched-push-timeout=40000 width=1280 height=720 live-source=TRUE ! queue ! nvvideoconvert ! queue ! \
nvinfer config-file-path="/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_infer_primary.txt" ! queue ! nvvideoconvert ! \
emcustom custom-lib=PATH_TO_YOUR_LIBRARY  ! fakesink

> 

> 最初の10分で2MB増加しましたが、その後の20分は1MB増加となり、特に顕著な増加傾向は見られませんでした。

再度上記の通り実行してみましたが、やはりご報告のような増加は見られませんでした。

お持ちの環境で上記のコマンドを実行して、メモリ増加量がどうなるか、ご確認お願いします。

2023年5月8日月曜日 17:13:03 UTC+9 ts...@edgematrix.com:

[w. ito]

お世話になっております。

上記のコマンドを参考に以下のコマンドを実行してメモリ増加量を確認したところ、
メモリ増加量が15分で10MBほどの増加量となり、増加量の減少がみられました。

gst-launch-1.0 uridecodebin3 uri="file:///mnt/nvme/toolkit_home/movies/river004_30min_1280x720.mp4" ! queue ! \

nvstreammux0.sink_0 nvstreammux name=nvstreammux0 batch-size=1 batched-push-timeout=40000 \
width=1280 height=720 live-source=TRUE ! queue ! nvvideoconvert ! queue ! \

nvinfer config-file-path="/mnt/nvme/toolkit_home/applications/RiverMonitoringApp/resource/water_segmentation_config_semantic_debug.txt" ! queue ! \
nvvideoconvert ! \
emcustom custom-lib="/mnt/nvme/toolkit_home/libs/gst-emcustom/build/developers/libpostwatersemseg.so" ! fakesink

上記コマンドとEAPのCLI実行でメモリ増加量に差があるということは
コマンドとCLI実行の処理内容の差分に原因があるかと思うのですが、具体的にはcallback処理などが被疑個所になるのでしょうか。

以上、ご確認のほどよろしくお願いいたします。

2023年5月9日火曜日 10:40:59 UTC+9 ts...@edgematrix.com:

[Takenori Sato]

ご確認ありがとうございます。

> 上記コマンドとEAPのCLI実行でメモリ増加量に差があるということは

> コマンドとCLI実行の処理内容の差分に原因があるかと思うのですが、具体的にはcallback処理などが被疑個所になるのでしょうか。

「メモリ増加量が15分で10MBほどの増加量」がそもそも大きいのが非常に気になるところで、

この増加は次の15分も同じでしょうか？

CLIで動くcallbackなどは別プロセスで動いておりますので、パイプラインで見られるメモリ増加とは無関係です。

2023年5月12日(金) 10:44 w. ito <wataru3...@gmail.com>:

[w. ito]

お世話になっております。

> 「メモリ増加量が15分で10MBほどの増加量」がそもそも大きいのが非常に気になるところで、

> この増加は次の15分も同じでしょうか？

こちら、15分で動画の読み込みが終わったのでその後のメモリ増加はありませんでした。
1280*720の解像度で1時間程度の動画でも処理を行ってみましたが、処理時間は36分程度で
メモリ増加量は28MBとなりました。
先の15分で10MBの増加と同じような増加量に思えますが、
佐藤様の検証時との差はカスタムコードから来るものなのでしょうか。
他に思い当たる差異としては使用しているモデルですが
こちらの検証時では14MB程度のセグメンテーションモデルを使用しています。

以上、よろしくお願いいたします。

2023年5月12日金曜日 11:04:43 UTC+9 Takenori Sato:

[ts...@edgematrix.com]

お世話になっております。

現時点では以下の３つの要因があると考えられます。

1. nvinferのカスタムライブラリを使用している場合は、そのカスタムライブラリ
2. emcustomのカスタムライブラリ
3. 環境の問題

まず、1の切り分けのため、emcustomを除外した以下を同様に実行して使用量の増加があるか、確認してみてください。

gst-launch-1.0 uridecodebin3 uri="file:///mnt/nvme/toolkit_home/movies/river004_30min_1280x720.mp4" ! queue ! \

nvstreammux0.sink_0 nvstreammux name=nvstreammux0 batch-size=1 batched-push-timeout=40000 \
width=1280 height=720 live-source=TRUE ! queue ! nvvideoconvert ! queue ! \

nvinfer config-file-path="/mnt/nvme/toolkit_home/applications/RiverMonitoringApp/resource/water_segmentation_config_semantic_debug.txt" ! fakesink

2023年5月15日月曜日 16:44:31 UTC+9 w. ito:

[w. ito]

お世話になっております。

いただいたコマンドでメモリ使用量を観察しましたが、

1時間程度の動画処理に35分かかり、その間のメモリ増加量は30MBほどでした。
また、モデルによって差異があるのかの確認のため

config_file_path="/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_infer_primary.txt"
としてサンプルの物体検出モデルでも同様に検証を行いましたが

1時間程度の動画処理に4分弱、メモリ増加量は26MBでした。

サンプルモデルを使用してもそちらで行われた検証時よりメモリ使用量が多いのですが

読み込ませている動画もしくはこちらで使っている端末環境固有の問題ということになるのでしょうか。

2023年5月15日月曜日 18:02:15 UTC+9 ts...@edgematrix.com:

[Takenori Sato]

ご確認ありがとうございます。

少なくとも、emcustomなしでご報告された増加量相当が見られますので、

DeepStreamのパイプラインだけで増加が発生している状態と言えます。

何か固有の環境問題がありそうに思いますが、

少なくともカスタムコード起因の増加はなさそうですので、

サービスボックスでのメモリ使用量をご確認ください。

デバイス詳細画面で、ステータスに以下のような項目があります。

システム全体のメモリ使用量ですが、ご報告の増加量だとここで明らかな増加が見られるはずです。

"ram_used_percent": 41.9,

2023年5月17日(水) 15:39 w. ito <wataru3...@gmail.com>:

[w. ito]

お世話になっております。

> 少なくともカスタムコード起因の増加はなさそうですので、

そうなのですか？
emcustomありの場合ですとメモリ増加量が1時間で700MB程度と更に増えるので
カスタムコード側にも別で原因があるのかと思っておりました。

> サービスボックスでのメモリ使用量をご確認ください。

サービスボックスで動作させているEAPはemcustomありのものですが
おっしゃる通り ram_used_percentを確認すると 10:41時点で35.4だったものが11:12時点では91.3となるなど明らかな増加が見られました。

2023年5月17日水曜日 17:43:15 UTC+9 Takenori Sato:

[Takenori Sato]

> 10:41時点で35.4だったものが11:12時点では91.3となるなど明らかな増加が見られました。

こちら、失礼しました。

v2.5ではないサービスボックスですよね？

だとすると、メタデータのリークが修正されていませんので、

切り分けできませんでした。

サービスボックスの情報を別途いただけましたら、

v2.5ベータ環境にアップグレードしますので、

別途ご連絡ください。

2023年5月18日(木) 13:06 w. ito <wataru3...@gmail.com>:

[Takenori Sato]

> サービスボックスの情報を別途いただけましたら、

> v2.5ベータ環境にアップグレードしますので、

> 別途ご連絡ください。

もしくは、対象アプリがどれか教えていただければ、

こちらのv2.5ボックスで動作確認してみます。

2023年5月18日(木) 13:15 Takenori Sato <ts...@edgematrix.com>:

[w. ito]

ご案内ありがとうございます。

はい、サービスボックスのバージョンは2.3.6-5で2.5にはしていないです。
よろしければそちらのv2.5ボックスでの動作確認をお願いしたいのですがよろしいでしょうか。
対象アプリは「 River Monitoring App (ESv2 AI Box NX版)  」でリビジョンは0.1.230330です。

以上、お手数おかけしますが、よろしくお願いいたします。

2023年5月18日木曜日 13:24:38 UTC+9 Takenori Sato:

[Takenori Sato]

> 対象アプリは「 River Monitoring App (ESv2 AI Box NX版)  」でリビジョンは0.1.230330です。

Submission Packageを見つけましたので、

こちらで動作確認してみます。

2023年5月18日(木) 17:20 w. ito <wataru3...@gmail.com>:

[Takenori Sato]

Submission Packageで確認しましたが、gstdのRESが明らかに異常な増加を示すので、

長時間動かさずともリークしていることがすぐ分かりました。

これで、まず環境要因は消えました。

そこで改めて怪しい部分ですが、

nvinferではカスタムパーサーを使っていませんので、ここのリークの可能性はなさそうで、

となるとやはりカスタムライブラリ部分なのですが、Segmentationのオーバーレイを出されているので、

これに絡む部分な気がします。

ちなみに、emcustomのprocess_ipで渡されるvideo_dataを、

セグメンテーション情報で書き換えて、表示しているということで合っているでしょうか？

2023年5月18日(木) 18:12 Takenori Sato <ts...@edgematrix.com>:

[w. ito]

ご確認ありがとうございます。

セグメンテーション結果の書き換えの部分が怪しいとのこと承知いたしました。
> ちなみに、emcustomのprocess_ipで渡されるvideo_dataを、

> セグメンテーション情報で書き換えて、表示しているということで合っているでしょうか？

はい、セグメンテーション結果の確認のためにvideo_dataを色情報で上書きして出力しています。

2023年5月18日木曜日 18:40:45 UTC+9 Takenori Sato:

[Takenori Sato]

> > セグメンテーション情報で書き換えて、表示しているということで合っているでしょうか？

> はい、セグメンテーション結果の確認のためにvideo_dataを色情報で上書きして出力しています。

そうしましたら、その部分を抜き出した再現可能なコードが用意できましたら、

こちらでも解析しますので、ご確認お願いします。

2023年5月19日(金) 10:06 w. ito <wataru3...@gmail.com>:

[w. ito]

お世話になっております。

video_dataの上書き部分を抜き出したコードが用意できましたので添付します。

お手数ですがご確認のほどよろしくお願いいたします。

2023年5月19日(金) 10:18 Takenori Sato <ts...@edgematrix.com>:

[Takenori Sato]

お世話になっております。

来週以降になってしまいますが、確認させていただきます。

2023年5月22日(月) 15:19 w. ito <wataru3...@gmail.com>:

[ts...@edgematrix.com]

お世話になっております。

EMI Semantic Segmentationのテンプレートで、

post processのemcustomをcolor_fill_sample.cで置き換えて、

動作確認したところ、確かに同様のリークが確認できました。

また、enable_coloringをfalseにすると、

リークのレートが大きく減少することも確認できました。

以上のことから、video_dataの書き換え部分でリークが発生しているようですが、

そちらの環境でも同様でしょうか？

2023年5月24日水曜日 10:06:19 UTC+9 ts...@edgematrix.com:

[w. ito]

お世話になっております。
お返事が遅れて申し訳ありません。

こちらの動作確認をいただいた環境はv2.5のtoolkitboxでしょうか。
こちらのtoolkitboxはv2.5へのアップグレードが正常に完了していない状態なことが気になるので、
一度再キッティングをしてきれいなv2.5の状態で再度検証を行いたいのですが
再キッティングをお願いしてもよろしいでしょうか。

以上、お手数おかけしますがなにとぞよろしくお願いいたします。

2023年6月2日金曜日 18:18:01 UTC+9 ts...@edgematrix.com:

[Takenori Sato]

お世話になっております。

> こちらのtoolkitboxはv2.5へのアップグレードが正常に完了していない状態なことが気になる

はい。v2.5で確認しております。

> 以上のことから、video_dataの書き換え部分でリークが発生しているようですが、

> そちらの環境でも同様でしょうか？

これについてはいかがでしたでしょうか？

こちらでは、この観点を中心に解析を続けておりますので、

もうしばらくお待ちください。

2023年6月15日(木) 10:27 w. ito <wataru3...@gmail.com>:

[w. ito]

ご確認ありがとうございます。

コードの検証の前に端末固有の問題がないかをクリアしたい意図で再キッティングをお願いできないか確認しておりました。 

以前このQA内でemcustomを除外した以下のコマンドでもリークが確認できたため 

端末固有の問題もコードとは別であるのではないかと議論した記憶があります。 

gst-launch-1.0 uridecodebin3 uri="file:///mnt/nvme/toolkit_home/movies/river004_30min_1280x720.mp4" ! queue ! \ nvstreammux0.sink_0 nvstreammux name=nvstreammux0 batch-size=1 batched-push-timeout=40000 \ width=1280 height=720 live-source=TRUE ! queue ! nvvideoconvert ! queue ! \ nvinfer config-file-path="/mnt/nvme/toolkit_home/applications/RiverMonitoringApp/resource/water_segmentation_config_semantic_debug.txt" ! fakesink 

実際に2023/5/17 17:43にこのQA内でも以下のような回答をいただいております。 

少なくとも、emcustomなしでご報告された増加量相当が見られますので、 
DeepStreamのパイプラインだけで増加が発生している状態と言えます。 
何か固有の環境問題がありそうに思いますが、 
少なくともカスタムコード起因の増加はなさそうですので、

この状態で解析を進めるよりは一旦再キッティングいただき、端末固有の問題がないことをクリアしてから
解析を進めた方がより問題箇所がわかりやすくなるかと思うのですがいかがでしょうか。

お忙しいところ申し訳ありませんが、ご確認のほどよろしくお願いいたします。

2023年6月15日(木) 12:00 Takenori Sato <ts...@edgematrix.com>:

[Takenori Sato]

お世話になっております。

確かに他にも色々動きに疑問な点がありますので、

再キッティングしましょう。

担当者へ繋ぎますので、一旦私までメールでご連絡お願いします。

2023年6月15日(木) 12:31 w. ito <wataru3...@gmail.com>:

[w. ito]

お世話になっております。

時間が空いてしまいましたが、
再キッティングいただきましたNX-Indoorで再度CLI実行時のメモリ使用量を計測したところ
キッティング前と同様にメモリリークが確認できました。

添付のpost_semseg.cの58行目

　*out_meta = json_to_string ( output_node, TRUE );

のコメントアウト有無でメモリ使用量を計測したところ
コメントアウト無しつまりjson_to_string実行時にそうでないときと比べて
70MBほどメモリ使用量が増えていることが確認できました。

なので端末固有の問題ではなく、コードに問題があるということになるのですが
どのような修正を行えばリークが解消されるのかご教示いただけますでしょうか。

行った検証は以下です。
①添付のpost_semseg.cをビルド

②CLIでアプリを実行

③watch -n 10 -d 'ps auxf | grep gstd | tee -a ./runcli.log'　でgstdプロセスのメモリ使用量を計測

④上記①～③をpost_semseg.cの58行目のコメントアウト有無で違いを検証する

2023年6月19日(月) 17:02 Yumin Nagakubo <ynag...@edgematrix.com>:

NTTコムウェア　伊藤様

お世話になっております。EDGEMATRIX 長久保です。

本AIBoxのv2.5環境（プロダクション/poc）再キッティングが完了いたしました。

本日、同封いただいている佐川の伝票にて返送手配をさせていただきました。

引き続きなにとぞよろしくお願いします。

EDGEMATRIX Inc.

長久保 佑民

2023年6月16日(金) 13:19 w. ito <wataru3...@gmail.com>:

承知いたしました。

本日発送しましたので

届きましたらキッティングのほどよろしくお願いいたします。

以上、よろしくお願いいたします。

2023年6月16日(金) 10:04 Takenori Sato <ts...@edgematrix.com>:

伊藤様

はい、弊社オフィスまでお願いします。

佐藤

2023年6月15日(木) 17:59 w. ito <wataru3...@gmail.com>:

佐藤様

ありがとうございます。

承知いたしました。

送付先は恵比寿西CATビル9階でよろしかったでしょうか。

2023年6月15日(木) 17:49 Takenori Sato <ts...@edgematrix.com>:

NTTコムウェア　伊藤様

承知しました。それでは、弊社長久保宛にお送りください。

Yumin、ツールキットボックス再キッティングの依頼です。

お手数ですが、v2.5環境（プロダクション/poc）に再キッティングをお願いします。

工藤さん、もし何か不都合があれば、フォローお願いします。

佐藤

2023年6月15日(木) 17:19 w. ito <wataru3...@gmail.com>:

お世話になっております。

承知いたしました。

佐藤様へ個別に返信しております。

お手数ですが、再キッティングの担当者様をご紹介いただけますでしょうか。

2023年6月15日(木) 17:04 Takenori Sato <ts...@edgematrix.com>:

[ts...@edgematrix.com]

お世話になっております。

メタデータ関連リーク修正（参考スレッド）が入ったv2.5環境でも、

リークが確認できたとのこと、承知しました。

こちらでも動作確認をしてみますので、しばらくお待ちだくさい。

2023年8月3日木曜日 16:00:31 UTC+9 w. ito:

[w. ito]

お世話になっております。

こちらの動作確認の状況はいかがでしょうか。
お忙しいところ恐縮ですが、いつ頃確認結果がわかりそうかの目安などいただくことできますでしょうか。

2023年8月14日月曜日 11:39:40 UTC+9 ts...@edgematrix.com:

[ts...@edgematrix.com]

遅くなって申し訳ありません。

確認は本日中に行なって、こちらに報告させていただきます。

2023年8月31日木曜日 10:04:42 UTC+9 w. ito:

[ts...@edgematrix.com]

> 確認は本日中に行なって、こちらに報告させていただきます。

共有いただいたpost_semseg.cを実行すると、

確かに毎分２〜３MB程度のリークが確認できました。

コードを確認すると、以下の部分が、最後にfreeされておりませんでした。

  /* Cleanup JSON */
  json_node_unref (output_node) ;
  g_object_unref ( builder ); // out_meta builder

以下のJson Nodeのドキュメントに説明がある通り、

JSONNodeはunrefしてカウントが0になってからfreeする必要があります。

https://developer-old.gnome.org/json-glib/unstable/json-glib-JSON-Node.html#JsonNode

実際、json_node_free (output_node)をunrefの後で呼ぶと、

メモリーリークがなくなることが確認できましたので、

この修正の上、再度ご確認ください。

2023年8月31日木曜日 11:55:37 UTC+9 ts...@edgematrix.com:

[w. ito]

確認いただきありがとうございます。

json_node_unrefを実行した後にjson_node_freeしたところメモリリークがなくなったとのこと、
承知いたしました。
こちらでも確認してみます。

2023年8月31日木曜日 14:23:09 UTC+9 ts...@edgematrix.com:

[w. ito]

お世話になっております。

いただきましたご回答を参考に以下のように
json_node_unrefを実行した後にjson_node_freeを実行するようにしたのですが
メモリ使用量の減少が確認できませんでした。
恐れ入りますが、佐藤様が検証に使用したソースコードを共有いただいてもよろしいでしょうか。
以下に当方が検証に使用したソースコードを示します。

ーーーーーーーーーーーーーーーーーーーーーーーーー

#include "emcustom.h"
#include <stdio.h>
#include <glib.h>
#include "gstnvdsmeta.h"
#include "gstnvdsinfer.h"
#include <json-glib/json-glib.h>

#define RGBA_PIXEL_WIDTH 4
#define I420_N_PLANES 3

void
process (const struct video_data *in_buffer, const char *in_meta,
    struct video_data *out_buffer, char **out_meta, const char *options,
    const char *events, GstBuffer *buffer)
{
  /* Not implemented in this app */
}


void
process_ip (struct video_data *io_buffer, const char *in_meta, char **out_meta,
    const char *options, const char *events, GstBuffer *buffer)
{
  /* def */
  JsonBuilder* builder;
  JsonNode* output_node;
  builder = json_builder_new ();
  // Array
  json_builder_begin_array ( builder ); // out_array Start
  // Object in array
  json_builder_begin_object ( builder ); // object Start
  json_builder_set_member_name ( builder, "hoge" );
  json_builder_begin_array ( builder ); // hoge Start
  // // Object in hoge 001
  json_builder_begin_object ( builder );
  json_builder_set_member_name ( builder, "name" );
  json_builder_add_string_value ( builder, "aaaa" );
  json_builder_set_member_name ( builder, "value" );
  json_builder_add_double_value ( builder, 0.123 );
  json_builder_end_object ( builder );
  // // Object in hoge 002
  json_builder_begin_object ( builder );
  json_builder_set_member_name ( builder, "name" );
  json_builder_add_string_value ( builder, "bbbb" );
  json_builder_set_member_name ( builder, "value" );
  json_builder_add_double_value ( builder, 0.234 );
  json_builder_end_object ( builder );
  // // Object in hoge 003

  // Close hoge
  json_builder_end_array ( builder ); // hoge End
  json_builder_end_object ( builder ); // object End
  // Close Array
  json_builder_end_array ( builder ); // out_array End

  /* Generate and set Out Meta String */
  output_node = json_builder_get_root ( builder );

  *out_meta = json_to_string ( output_node, TRUE );

  /* Cleanup JSON */
  json_node_unref (output_node) ;

  json_node_free (output_node);

  g_object_unref ( builder ); // out_meta builder
}

ーーーーーーーーーーーーーーーーーーーーーーーーー

2023年8月31日木曜日 17:06:37 UTC+9 w. ito:

[ts...@edgematrix.com]

お世話になっております。

ご提供いただいたソースに、

json_node_free (output_node);

を追加したもので、以下の通り確認しました。

2023年9月8日金曜日 18:13:15 UTC+9 w. ito:

[w. ito]

お世話になっております。

検証に使用したソースを共有いただきありがとうございます。
当方が検証に用いたものと同じ内容なように見えるのですが、結果が違うのが気になります。
恐れ入りますが同様の結果になるか確認したいので、検証手順も共有いただいてもよろしいでしょうか。

2023年9月12日火曜日 7:37:36 UTC+9 ts...@edgematrix.com:

[w. ito]

お世話になっております。

お忙しいところ恐れ入りますが、
上記で質問させていただいています検証手順について、同条件での比較を行いたいので
共有いただけますと幸いです。

2023年9月12日火曜日 11:19:43 UTC+9 w. ito:

[Takenori Sato]

お世話になっております。回答遅れて失礼しました。

これまでと同様、CLIで実行し、TOPでRSSを確認しました。

2023年9月15日(金) 9:48 w. ito <wataru3...@gmail.com>:

[w. ito]

お世話になっております。

こちらも返答遅くなり申し訳ありません。
>  これまでと同様、CLIで実行し、TOPでRSSを確認しました。
弊社環境の検証ではpsコマンドを使用してRSSを確認していましたので
もしかしたらそこに違いがあるかもしれません。
念のためtopコマンドでも確認してみようと思いますが、
同条件で比較したいので具体的なコマンドを共有いただけますでしょうか。

2023年9月15日金曜日 10:57:17 UTC+9 Takenori Sato: