Skip to main content

进程异常时资源清理的处理建议

Event数量超过上限导致aclrtRecordEvent接口返回失败​

现象描述​

调用aclrtRecordEvent接口在Stream中记录一个Event时，日志中的报错如下，红框中是关键日志信息，提示Event ID申请失败：

可能原因​

分析上述日志信息，可能存在以下故障原因：Event ID的数量超过上限。

处理步骤​

多Stream之间同步等待的场景下，Event ID的资源时可以复用的，复用Event ID的流程是：在调用aclrtRecordEvent接口+aclrtStreamWaitEvent接口后，若指定的Event已完成，则需要及时调用aclrtResetEvent接口释放Event资源。

需要用户按照复用Event ID的流程优化代码逻辑。

父主题： FAQ

进程异常退出后重新执行任务失败​

现象描述​

进程异常退出时，包括强行终止任务（如ctrl + c或者kill命令终止进程）的场景，然后重新启动任务失败。

可能原因​

进程异常退出时，只能依赖系统检测到程序退出后才进行资源释放，释放资源最长需要一分钟的执行时间。如果在未执行完资源释放前执行新的任务，可能导致新执行的任务失败。

处理步骤​

进程异常退出后需要等待一分钟，才能保证下一次重新执行任务成功。

父主题： FAQ

进程异常时资源清理的处理建议​

现象描述​

用户捕获异常退出信号，并在信号处理函数中释放已申请资源，下一次执行时会报执行失败。此时查看日志，会发现如图1所示报错。

图1 unbind model stream failed

可能原因​

进程异常时，host侧内核态驱动会自动检测并发起对应进程device侧资源释放的流程，不需要用户捕获进程异常的信号并主动完成清理。若用户主动释放，会影响到系统的资源释放流程。

处理步骤​

用户无需关注进程异常退出信号。

父主题： FAQ

用户进程异常退出后重启进程失败​

现象描述​

用户进程卡住或者用户强制退出进程后，再次重启，重启后发现进程无法正常启动。类似的日志信息如下：

AscendCL日志信息：aclrtProcessReport failed

aclrtProcessReport failed, ret = 107012
aclrtProcessReport failed, ret = 107012

Runtime日志信息：halResourceIdAlloc xxx failed

[ERROR] DRV(2086,rtstest_host):2021-06-09-02:14:46.034.368 [ascend][curpid: 2086, 2086][drv][tsdrv][halResourceIdAlloc 477]id is exhausted, type(0 stream), range[0, 1024), dev_id(0), tsid(0).
[ERROR] RUNTIME(2086,rtstest_host):2021-06-09-02:14:46.034.380 [npu_driver.cc:285]2086 StreamIdAlloc:[driver interface] halResourceIdAlloc streamid failed: device_id=0, tsId=0, drvRetCode=48!
[ERROR] RUNTIME(2086,rtstest_host):2021-06-09-02:14:46.034.401 [stream.cc:448]2086 Setup:Failed to alloc stream id, retCode=0x702001a.
[ERROR] RUNTIME(2086,rtstest_host):2021-06-09-02:14:46.034.416 [context.cc:1251]2086 StreamCreate:Setup stream failed, retCode=0x702001a.
[ERROR] RUNTIME(2086,rtstest_host):2021-06-09-02:14:46.034.440 [logger.cc:211]2086 StreamCreate:Create stream failed, priority=7 ,flags=0.
[ERROR] RUNTIME(2086,rtstest_host):2021-06-09-02:14:46.034.458 [api_c.cc:461]2086 rtStreamCreateWithFlags:ErrCode=207008, desc=[driver error:no stream resource], InnerCode=0x702001a
[ERROR] RUNTIME(2086,rtstest_host):2021-06-09-02:14:46.034.469 [error_message_manage.cc:26]2086 ReportFuncErrorReason:rtStreamCreateWithFlags execute failed, reason=[driver error:no stream resource]

可能原因​

通过日志分析无法正常重启的原因可能是public taskid、stream id、eventid等资源申请不到引起的：

  • 资源已经被其他进程占用完。
  • 上一个进程退出时还未完全释放完资源。

处理步骤​

针对上述可能原因，可以按以下方式处理：

  • 等待一分钟后再重新启动进程，保证上一个进程资源释放完成。
  • 停止其他进程或者等其他进程执行完成后再启动进程。
  • 如果通过上述方式处理后仍然申请失败，建议检查是否超过了可用的资源上限，如果未超上限，则需要重启环境强行释放资源、恢复环境。

父主题： FAQ

VDEC视频解码异常导致进程卡死，无法退出​

现象描述​

用户进程卡死，无法退出。

查看应用类日志，一直重复提示信息“fault kernel_name=DvppSendVdecFrame”、“Kernel task happen error, retCode=0x28, [aicpu timeout]”，表示AI CPU异常，无法处理VDEC解码任务，导致任务超时。

日志片段举例如下：

[ERROR] RUNTIME(pid,pName):DateTimeMS [task.cc:878]1827 PreCheckTaskErr:[DVPP][DEFAULT]Kernel task happen error, retCode=0x28, [aicpu timeout].
[ERROR] RUNTIME(pid,pName):DateTimeMS [task.cc:676]1827 PrintAicpuErrorInfo:[DVPP][DEFAULT]Aicpu kernel execute failed, device_id=0, stream_id=177, task_id=4, fault so_name=libdvpp_kernels.so, fault kernel_name=DvppSendVdecFrame, fault op_name=, extend_info=.
[ERROR] RUNTIME(pid,pName):DateTimeMS [task.cc:878]1831 PreCheckTaskErr:[DVPP][DEFAULT]Kernel task happen error, retCode=0x28, [aicpu timeout].
[ERROR] RUNTIME(pid,pName):DateTimeMS [task.cc:676]1831 PrintAicpuErrorInfo:[DVPP][DEFAULT]Aicpu kernel execute failed, device_id=0, stream_id=170, task_id=8, fault so_name=libdvpp_kernels.so, fault kernel_name=DvppSendVdecFrame, fault op_name=, extend_info=.
[ERROR] RUNTIME(pid,pName):DateTimeMS [engine.cc:960]1766 ReportExceptProc:[DVPP][DEFAULT]Task exception! device_id=0, stream_id=107, task_id=8, type=1, retCode=0x28.
[ERROR] RUNTIME(pid,pName):DateTimeMS [engine.cc:960]1773 ReportExceptProc:[DVPP][DEFAULT]Task exception! device_id=0, stream_id=130, task_id=4, type=1, retCode=0x28.

可能原因​

Device内存不足，AI CPU无法处理VDEC解码任务，导致任务超时。

处理步骤​

  1. 在使用媒体数据处理V1版本的VDEC视频解码功能前，可参考功能及约束说明中“每路VDEC解码的内存消耗计算公式”，预估需使用的Device内存，并合理规划Device上的内存。

  2. 优化应用程序的代码逻辑，增加异常处理机制，获取VDEC解码异常信息，强制退出进程。

    在调用aclinit接口之后，定义异常回调函数，并调用aclrtSetExceptionInfoCallback接口设置异常回调函数，用于获取任务异常信息，以便在异常分支中根据任务异常信息来判断是否退出应用进程。

    基本接口调用逻辑如下：

    1. 定义并实现异常回调函数fn(aclrtExceptionInfoCallback类型)，回调函数原型为：typedef void (*aclrtExceptionInfoCallback)(aclrtExceptionInfo *exceptionInfo)

      在异常回调函数fn内调用aclrtGetDeviceIdFromExceptionInfo、aclrtGetStreamIdFromExceptionInfo、aclrtGetTaskIdFromExceptionInfo接口分别获取Device ID、Stream ID、Task ID。

      根据Stream ID、Task ID判断Device是否异常，若异常，则强制退出进程。

      异常回调函数实现示例如下：

      void dvpp_callback(aclrtExceptionInfo * exception_info)
      {
          uint32_t taskId = aclrtGetTaskIdFromExceptionInfo(exception_info);
          uint32_t streamId = aclrtGetStreamIdFromExceptionInfo(exception_info);
          uint32_t deviceId = aclrtGetDeviceIdFromExceptionInfo(exception_info);

          if(taskId == 0xffffffff) || (streamId == 0xffffffff) {
              //Device异常，强制退出进程
          } else {
              //任务异常，如果频繁出现（例如，统计1秒内触发异常回调函数的次数），进程退出
          }
          return;
      }

    2. 调用aclrtSetExceptionInfoCallback接口设置异常回调函数。

    3. 执行VDEC解码，接口调用流程请参见VDEC视频解码。

父主题： FAQ

buf_size参数设置不合理导致视频编码异常​

视频编码场景下，需通过hi_venc_attr结构体中buf_size参数值来设置编码缓冲区的内存大小，buf_size参数值设置地不合理，可能会导致视频编码耗时长或编码失败。

现象及可能原因（Ascend RC）​

视频编码耗时长或编码失败的场景下，使用proc命令排查问题，proc查询结果中关键信息含义如下：EncStart表示启动编码的帧数，EndSuccessed表示成功编码的帧数，Lost和Disc（Disacrd）表示编码失败的帧数，Recode表示重编的次数。

  1. 编码进程运行过程中，登录Device。
  2. 执行命令cat /proc/umap/h265e或者cat /proc/umap/h264e。

    • 出现类似下面红框的现象：Lost和Disc的数量为0或很低，但是Recode的数量比较大，表示大部分帧能够编码成功，但是重编次数太多。

      当实际的编码结果大小大于编码缓冲区中的可用内存大小时，编码模块会自动调整参数重编，减小编码结果数据大小。因此buf_size设置的太小，缓冲帧数少，导致出现重编的概率高，进而导致编码时延增加，帧率变低，性能下降。

    • 出现类似下面红框的现象：Lost和Disc的数量比较大，同时Recode的数量也比较大，表示有比较多的帧编码失败了。

      当实际的编码结果大小大于编码缓冲区中的可用内存大小时，编码模块会自动调整参数重编，减小编码结果数据大小。如果重编次数全部用完，但是编码结果大小依然大于编码缓冲区中的可用内存大小，此时编码模块会将该帧丢弃。因此buf_size设置的太小，缓冲帧数少，导致出现重编的概率高，丢帧概率高。

处理步骤​

创建编码通道时，合理设置buf_size参数，具体参见hi_venc_attr结构体中buf_size成员的说明。

父主题： FAQ

在线提单