OdroidN2+平台录音C程序无报错挂起及内存泄漏排查求助

我在OdroidXU4（arm7l架构）和OdroidN2+（aarch64架构）上运行同一录音程序实现24/7录音，分别针对对应架构编译main.c。程序在OdroidXU4上稳定运行无异常，但在OdroidN2+上仅能正常录制前4个时长1小时的文件，录制第5个文件时无报错但出现挂起。

使用valgrind调试内存泄漏，堆摘要显示存在3块明确丢失的内存：

• 第一块可在main函数中通过free释放
• 第二、三块显示为???，无法定位泄漏位置，怀疑与依赖库相关

已升级OdroidN2+上的libportaudio和libasound2并重新编译程序，但问题仍未解决。现求助：

1. 如何解决程序挂起问题
2. 如何定位第二、三块内存泄漏的位置

一、定位???标记的内存泄漏 #

valgrind显示???通常是因为依赖库缺少调试符号，导致无法解析库内部的调用栈。可按以下步骤处理：

• 安装库的调试包：针对Debian/Ubuntu系系统，执行sudo apt-get install libportaudio2-dbg libasound2-dbg，安装后重新用valgrind运行程序，即可显示库内的完整调用栈，定位泄漏位置。
• 若调试包不可用，手动编译带调试信息的依赖库：
  1. 下载portaudio和alsa-lib的官方源码
  2. 编译时添加-g参数保留调试信息，示例命令：

     ./configure CFLAGS="-g" && make && sudo make install
     

  3. 重新编译你的录音程序，确保链接到新编译的带调试信息的库
• 用valgrind的完整参数重新检测：

  valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./your-recorder-program
  

  此时应能显示第二、三块泄漏内存的完整调用链路。

二、解决程序挂起问题 #

挂起可能与内存泄漏累积、音频资源未正确释放或架构相关的逻辑异常有关，可按以下步骤排查：

• 先处理内存泄漏：即使是库的泄漏，也可通过每次录制完成后重置音频上下文缓解。比如每次录制完一个文件后，调用Pa_Terminate()终止PortAudio，再重新调用Pa_Initialize()初始化，避免长期持有资源。
• 检查文件操作逻辑：确认第5个文件的路径、文件名生成是否正常，排查磁盘空间是否已满、文件权限是否异常（比如录制目录变为只读）。
• 增加关键节点日志：在音频流启动/停止、文件打开/关闭、内存分配/释放等位置添加日志，同时记录每次录制前后的内存使用情况（可调用getrusage()获取进程内存数据，或在外部用free -m定时监控），观察第5次录制前是否有资源耗尽迹象。
• 排查线程/锁状态：若程序使用多线程，当程序挂起时，用gdb attach到进程查看调用栈：

  gdb -p <进程ID>
  thread apply all bt
  

  确认程序卡在音频设备操作、文件IO还是某个锁等待上。
• 快速复现测试：编写简化版测试程序，循环录制短时长文件（比如1分钟），快速触发第5次录制，排查是否是时长相关的累积问题，缩小排查范围。

内容的提问来源于stack exchange，提问作者Susan