VPI 2.0 fatal assertion error

We see a Fatal assertion error similar to this thread when using VPI 2.0 on JP5.0dp.

Extracting a standalone example will take a while. Essentially this is thrown by a thread created inside VPI:

Fatal assertion error
#0 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0xa82e08) [0xfffff3612e08]
#1 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0xa8333c) [0xfffff361333c]
#2 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x50f80c) [0xfffff309f80c]
#3 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x50f9b4) [0xfffff309f9b4]
#4 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x6661a0) [0xfffff31f61a0]
#5 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x57c4c4) [0xfffff310c4c4]
#6 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x565238) [0xfffff30f5238]
#7 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x565394) [0xfffff30f5394]
#8 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x55a66c) [0xfffff30ea66c]
#9 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x575384) [0xfffff3105384]
#10 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0x5732bc) [0xfffff31032bc]
#11 /opt/nvidia/vpi2/lib64/libnvvpi.so.2(+0xc3341c) [0xfffff37c341c]
#12 /lib/aarch64-linux-gnu/libpthread.so.0(+0x751c) [0xfffff788951c]
#13 /lib/aarch64-linux-gnu/libc.so.6(+0xd122c) [0xfffff280522c]

We are using VPI to detect keypoints on a wrapped managed memory buffer.
All VPI calls are checked, there are no errors.


Would you mind checking if you are facing the same as topic 200021 first?

The issue can be reproduced with the VIC backend and vpiImageCreateCUDAMemWrapper image.
If changing to vpiImageCreateHostMemWrapper image, VPI can work correctly.

Do you observe similar behavior in your problem?


VPI2.0 unified the wrapper functions. There is only one function now, that takes the memory kind as an argument: vpiImageCreateWrapper().

In our case, we also use vpiImageSetWrapper() to change the wrapped memory buffer. So the VPIImage stays the same (dimensions, pixel type etc.), but we swap the buffer every frame. The buffer is globally attached managed memory, I vaguely remember that it was not possible to wrap it as host memory.

Also this happens while using the PVA for Harris Corner Detection, not touching the VIC at all.

There’s also some other unexpected behavior, the SetWrapper function complains that the image is locked even though we never explicitly lock it ourselves. As if it is locked by default during/after creation.

Extracting a clean example for reproducing the error will take a while. We could provide a part of our codebase under NDA, would that be possible?


The error of topic 200021 is specific to VIC, so you might something else.
It will be better if you can extract a clean reproducible source for this issue.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.