Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#216 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
cpp, python
Ambito
computer-vision, embedded-iot

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

中文摘要：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.

Lingua principale
Python
Stelle
850
Fork
128
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sipeed/MaixPy

Tutte le issue di sipeed/MaixPy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.