MaixCAM2: IVPS pool blocks leak on process exit (even with cam.close()), next camera process hangs in __AX_OSAL_SYNC_wait_interruptible

Open
  • Is something wrong?
#216 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
cpp, python
Domain
computer-vision, embedded-iot

Research direction

Start with components/vision/port/maixcam2/maix_camera_maixcam2.cpp, focusing on Camera::close(), channel teardown, and frame handling. Reproduce repeated process exits while monitoring /proc/ax_proc/pool; done means identifying a supported cleanup sequence or confirming that the binary driver fails to reclaim IVPS blocks and documenting the result.

Written by the indexing model from the issue text.

Description

中文摘要：MaixCAM2 上使用 camera.Camera 的进程每次退出后，IVPS 在公共池里有时会留下显存块不归还（显式 cam.close() 也一样），驱动不回收已退出进程的块；积累到公共池耗尽后，下一个打开摄像头的进程卡死在 __AX_OSAL_SYNC_wait_interruptible（或 VO init failed），只能整机重启恢复。数据见下。

Environment

  • Device: MaixCAM2 (AX630C, 4 GB), factory image, not reflashed
  • MaixPy 4.12.5, Axera SDK libs V3.0.0_20250319114413
  • App: a long-running MaixPy app using camera.Camera(640, 480, image.Format.FMT_RGB888), display.Display(), nn.FaceRecognizer, nn.YOLO11 (pose + detect), started from the launcher. A small supervisor process restarts it when it exits.

Symptom

After the app process is restarted a few times (SIGINT, clean exit through app.need_exit()), the next process hangs while initializing the camera / loading models. Its main thread sits in __AX_OSAL_SYNC_wait_interruptible forever; sometimes it fails with RuntimeError: VO init failed instead. Only a full reboot recovers. Killing and restarting the process does not.

What leaks

Reading /proc/ax_proc/pool about 1 s after the old process has exited (no MaixPy process running at that moment) still shows blocks "in use" by IVPS in common pool 1 (BlkSize 2764800, BlkCnt 6), for example:

PoolId IsComm ... BlkSize  BlkCnt FreeCnt
1      1      ... 2764800  6      2
Index BlockId    VIN IVPS VO ...
0     0x5E001000 0   1    0
2     0x5E001002 0   1    0
3     0x5E001003 0   1    0
5     0x5E001005 0   1    0

These blocks are never returned. Each start also leaves another set of private (non-common) pools behind (the pool id keeps growing), but that alone does not block anything.

Data

Restart loop: SIGINT the app, wait until its heartbeat resumes, repeat. "Residual" = blocks still in use 1 s after the old process exited.

Round Residual (original exit path) Residual (explicit ordered shutdown incl. cam.close() and disp.close()) New process
1 2 2 ok
2 2 2 ok
3 4 4 ok
4 5 5 hangs in __AX_OSAL_SYNC_wait_interruptible

A third run with the same code showed residuals 0, 0, 0, 1, 3 over five rounds, so the leak is intermittent. It looks like it depends on whether frames are still queued in the IVPS output at the moment of exit. It is not related to whether people are in view.

What I checked in MaixCDK

components/vision/port/maixcam2/maix_camera_maixcam2.cpp: Camera::close() calls ax_vi->del_channel() and ax_vi->deinit(), and read() wraps each popped frame in pipeline::Frame(frame, true), so frames handed to the user look released. The leaked blocks are owned by IVPS itself. That suggests frames left in the channel's output queue, or the group itself, are not released on del_channel/deinit, or that the driver does not reclaim blocks of a dead process. The pool/IVPS code is binary-only, so I cannot dig further.

Questions

  1. Is there an API or a required call sequence (e.g. draining the channel queue, stopping/destroying the IVPS group) that fully returns these blocks before exit?
  2. Can the driver reclaim pool blocks of a process that has exited?
  3. Is the common pool configuration (BlkCnt 6 for pool 1) adjustable, to give more headroom?

Workaround in use

After each app exit, a supervisor reads /proc/ax_proc/pool and reboots the device when 3 or more blocks are still held. Any code update is also followed by a full reboot rather than an app restart. This works, but a restart then costs about a minute instead of about 20 seconds.

Dominant language
Python
Stars
872
Forks
129
Avg merge
2h 5m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sipeed/MaixPy

All issues in sipeed/MaixPy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.