gst-launch-1.0 mppvideodec 内存线性增长

[daizichuan]

1、现场描述
1）gst-lauch-1.0 命令
gst-launch-1.0 -e
rtspsrc location="rtsp://admin:xxx@192.168.230.xxx:554/cam/realmonitor?channel=1&subtype=0" protocols=tcp
! rtph265depay
! h265parse
! mppvideodec
! fakesink sync=false > gst-launch.log &

2）运行一个周末dmesg里提示oom

3）后面又按照上面的命令，运行下面命令查看内存，测了一晚上，
cat /proc/$PID/smaps_rollup |
grep -E "Rss|Anonymous|Private_Dirty"
@@
Tue Jun 9 23:11:49 GMT-8 2026
Rss: 38684 kB
Private_Dirty: 25768 kB
Anonymous: 25768 kB
@@
Wed Jun 10 00:11:49 GMT-8 2026
Rss: 62448 kB
Private_Dirty: 49532 kB
Anonymous: 49532 kB
@@
Wed Jun 10 01:11:49 GMT-8 2026
Rss: 86132 kB
Private_Dirty: 73216 kB
Anonymous: 73216 kB
。。。

2、排错过程
1）生成本地 /tmp/test_annexb.h265
gst-launch-1.0 -e
rtspsrc location="rtsp://192.168.230.xxx:554/cam/realmonitor?channel=1&subtype=0"
user-id=admin
user-pw="xxx"
protocols=tcp
! rtph265depay
! h265parse config-interval=-1
! video/x-h265,stream-format=byte-stream
! filesink location=/tmp/test_annexb.h265

2）按照 buffer mode 三个模式 都跑了一遍，内存都oom
mpi_dec_test
-i /tmp/test_annexb.h265
-t 16777220
或
mpi_dec_test
-i /tmp/test_annexb.h265
-t 16777220
-bufmode i
或
mpi_dec_test
-i /tmp/test_annexb.h265
-t 16777220
-bufmode e

3、排除 h265 问题，摄像头 编码模式改成h264 内存还是线性增长
gst-launch-1.0 -e
rtspsrc location=rtsp://...
user-id=admin
user-pw=xxx
protocols=tcp
! rtph264depay
! h264parse
! mppvideodec
! fakesink

[daizichuan]

项目	信息	获取命令
SoC	RK3576	cat /proc/cpuinfo或cat /proc/device-tree/compatible
Linux Kernel	Linux host 6.1.0-1-xxx#xxxSMP Mon May 18 07:06:02 UTC 2026 aarch64 GNU/Linux	uname -a
BSP 版本	BusyBox v1.36.1 (2026-05-14 01:44:48 UTC) built-in shell (ash)	cat /etc/os-release
MPP 版本	2e93ab7 (2026-04-28)	mpp_info_test
MPP Package	librkmpp 1.0.11-1	ipkg-cl list | grep mpp
GStreamer Rockchip Plugin	1.14.4-1	ipkg-cl list | grep mpp
Decoder Plugin	mppvideodec	gst-inspect-1.0 mppvideodec
Encoder Plugin	mpph265enc	gst-inspect-1.0 mpph265enc
Input Stream	H.265 / HEVC	摄像头 RTSP
Resolution	2880x1620	mpp 日志
FPS	15fps	mpp 日志
Memory	1.91GB	free -m

[HermanChen]

到这里更新一一下 https://github.com/HermanChen/mpp

[daizichuan]

@HermanChen 您好，更新之后，问题还存在
~ # ipkg-cl list|grep mpp
gstreamer1-plugins-rkmpp - 1.14.4-1
librkmpp - 1.0.12-1
rkmpp - 1.0.12-1
~ #

[daizichuan]

更准确的描述是：
1、mpi_dec_test
升级前：执行十几秒，dmesg提示oom
升级后：执行几分钟，内存占用快满了，但是没有oom
2、gst-launch-1.0 mppvideodec
还是一样线性增长

[HermanChen]

mpi_dec_test -bufmode e 这种是固定分配的，应该不会有泄漏的问题
能看到是什么内存泄漏么，是一般 memory 还是 dmabuf，fd 有没有一直在增长？

[daizichuan]

@HermanChen
1、执行命令
mpi_dec_test
-i /root/test_annexb.h265
-t 16777220

2、监控命令
#!/bin/sh

PID=$(pidof mpi_dec_test)

while true
do
echo "========start============"
date
echo "===================="
cat /proc/$PID/smaps_rollup |
grep -E "Rss|Anonymous|Private_Dirty"
echo "========fd============"
ls -l /proc/$PID/fd | wc -l
echo "========fd dmabuf============"
ls -l /proc/$PID/fd | grep dmabuf | wc -l
echo "=========maps==========="
cat /proc/$PID/maps | grep dma
echo "==========fdinfo=========="
ls /proc/$PID/ | wc -l
echo "=========meminfo==========="
cat /proc/meminfo | grep -i cma
sleep 1
done

3、结果分析
只有 cat /proc/$PID/smaps_rollup |
grep -E "Rss|Anonymous|Private_Dirty" 三个参数 同步增加，且基本相等

[HermanChen]

fd 数量没增加的话，说明是一般的 malloc 有泄漏。可以打开 asan 分析看看

[daizichuan]

@HermanChen
您好，我们环境有valgrind和相关so库开起来debug信息，现排查得出如下结论，帮忙看一下您那边还需要我提供什么信息

🧪 排查方法（GDB + 统计）
1️⃣ hook关键释放路径

在 gdb 中对以下函数打断点并打印 bt：

h265d_frame_unref
h265d_build_rps
mpp_buf_slot_clr_flag
mpp_buffer_put_with_caller
mpp_frame_deinit
2️⃣ 运行后中断采样（10~20s）
run
Ctrl+C
bt 10
3️⃣ 统计调用栈来源

通过 bt 统计三条释放路径：

parser thread
hal/display thread
app deinit
4️⃣ 对比 ref / put / get 计数
p $get
p $put
p $ref
p $leak_cnt
📊 关键现象
1️⃣ 释放路径同时存在三条
parser thread:
h265d_build_rps → h265d_frame_unref

display thread:
mpp_dec_push_display → mpp_buf_slot_clr_flag

app layer:
mpp_frame_deinit → mpp_buffer_put
2️⃣ 计数异常
PUT > GET
REF ≈ PUT-1
buffer_total_now 持续增长
3️⃣ frame 生命周期冲突

同一 frame 被多个路径释放：

parser 已 unref
display 再 clr slot
app 再 deinit
🚨 结论（Root Cause）
❗MPP H265 frame/buffer 生命周期管理错误
本质问题：

frame / buffer 没有单一 owner，导致多路径重复释放

🔥 具体问题点：
h265d_build_rps() 错误触发 frame_unref
mpp_buf_slot_clr_flag() 与 frame_unref 并行释放
mpp_frame_deinit() 在已释放路径再次释放
🧩 影响
buffer refcount 错乱
slot 与 frame 生命周期不同步
PUT/GET 不平衡
内存持续增长 / OOM / 卡死
✅ 一句话总结

H265 decoder 中 frame/buffer 存在多线程多路径重复释放（parser + display + app），导致引用计数失控与生命周期冲突。

[HermanChen]

打开mpp_mem里的log然后辅助 AI 分析一下~

[daizichuan]

@HermanChen
您是要我这边分析到这个级别吗？我这边是测试人员，代码这边不懂，过多的参与可能会导致分析和引导有偏差

🚀 一、你现在其实已经不需要再跑“标准步骤”了

你问的这个：

🚀 三、标准步骤还需要执行吗？

❌ 不需要（原因很关键）

因为你已经完成了：

✔ PUT / DISCARD / FRAME INIT 已抓
✔ callstack 已确认
✔ mpp_mem counter overflow 已复现
✔ slot fail（release_list fail）已确认
✔ buffer put 路径已定位

👉 现在缺的不是“数据”，而是：

❗源码层“为什么 slot 没被正确释放”

🎯 二、最终 Root Cause（源码级结论）

结合你所有 gdb + log：

🔥 Root Cause 1（核心）
📍 文件位置（模块级）
rockchip_mpp / codec/h265d/h265d_frame.c
📍 问题函数
h265d_frame_unref()
❗问题本质
frame 引用释放时：
→ slot flag 被清
→ buffer put 被调用
❌ 但 slot node 没有从 release_list 正确移除
🔥 Root Cause 2（关键断点）
mpp_buf_slot_clr_flag()
❗问题本质
slot 状态清理 ≠ slot 生命周期结束
但代码里误以为已经结束
→ 导致 node 残留
→ release_list 查找失败
🔥 Root Cause 3（最致命）
release_list fail to find node
👉 含义非常明确：
buffer 已经 put 了两次路径：

• frame_deinit path
• parser/hal path

但 slot 已经提前释放 or 被重复释放
→ double free / stale pointer
🧠 三、完整源码问题链（你可以直接贴 issue）
h265d_parse()
↓
h265d_nal_unit()
↓
h265d_build_rps()
↓
h265d_frame_unref()
↓
mpp_buf_slot_clr_flag()
↓
mpp_buffer_put_with_caller()
↓
release_list fail to find node ❌

💥 四、最终结论（可以直接写 bug report）
Root cause:
Buffer slot lifecycle mismatch in H265 decoder

Issue:

1. frame_unref triggers buffer put correctly
2. but slot tracking (release_list) already lost node
3. causing double release or stale pointer
4. leads to mpp_mem node exhaustion (1024 limit)

Impact:

• memory counter overflow
• buffer recycle failure
• decode instability under long run

Suspected fix area:

• h265d_frame_unref()
• mpp_buf_slot_clr_flag()
• slot management in decoder context
  🔧 五、修复点（真正开发要改的地方）
  ✔ Fix 1（必须）
  在 slot release 时加 guard
  if (!slot->valid || !slot->node)
  return;

👉 防止 double release

✔ Fix 2（关键）
release_list 必须保证一致性
remove_node_from_release_list(slot)

必须在：

frame_unref → put → clr_flag

统一路径中只执行一次

✔ Fix 3（建议）
增加 debug assert
ASSERT(slot != NULL);
ASSERT(slot->in_use == 1);
🧾 六、你可以直接这样写 commit 级修复描述
Fix H265 decoder buffer slot lifecycle mismatch

• prevent double release in frame_unref path
• ensure release_list consistency with buffer put
• add slot validity check before discard
• fix stale node in buffer tracking list

Result:

• eliminate mpp_mem counter overflow (1024 limit)
• fix release_list fail to find node

[daizichuan]

我用夸克网盘分享了「mpp日志」，点击链接即可保存。打开「夸克APP」，无需下载在线播放视频，畅享原画5倍速，支持电视投屏。
链接：https://pan.quark.cn/s/98e244502280

上面网盘里的valgrind内存分析日志是我按照下面命令运行得出的

timeout 10s valgrind
--tool=memcheck
--leak-check=full
--show-leak-kinds=all
--num-callers=20
--log-file=/tmp/valgrind-mpi_dec_test.log
mpi_dec_test
-i /root/test_annexb.h265
-t 16777220

timeout 10s valgrind
--tool=memcheck
--leak-check=full
--show-leak-kinds=all
--num-callers=20
--log-file=/tmp/valgrind-gst-launch-1.0.log
gst-launch-1.0 -e
rtspsrc location="rtsp://admin:xxx@192.168.230.xxx:554/cam/realmonitor?channel=1&subtype=0" protocols=tcp
! rtph265depay
! h265parse
! mppvideodec
! fakesink sync=false

[daizichuan]

@HermanChen
您好，还需要我这边提供什么信息吗？