Intermittent "pure virtual method called" crash on CaptureSession cast as IEventProvider

I have software running on Jetson AGX using the Jetson Argus libraries. As part of my code, I have a CaptureSession object which I interface cast to an IEventProvider and call methods like createEventQueue.

I have this code (including this cast and createEventQueue call) running in a loop for several days without issue. However intermittently (once per several days) I’ll get a “pure virtual method called” crash. I have observed this crash within gdb, and the stack trace has boiled it down to the following pseudocode.

CaptureSession my_capture_session;
IEventProvider *iEventProvider = interface_cast<ICaptureSession>(my_capture_session);

What would cause this call to intermittently fail? I have some theory, e.g., about a flaky hardware connection causing the CaptureSession object to be deleted or put in an invalid state, but it’s hard to speculate into the internals of drivers and NVArgus.

hello nicolo,

may I first confirm which Jetpack release version you’re using.
it’s more like hardware problem since the failure is intermittently, with the low failure rate.

let’s try having below commands to boost all the VI/CSI/ISP clocks.
this also narrow down the issue to ignore system level clock configuration.
for example,

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked

cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

Thanks for the reply. We’re on Jetpack 4.4.

It ties up some hardware resources to look for this bug, so I just want to clarify:

Are you saying you believe locking the clocks to max frequency might make this bug go away?

Can lock the clock frequency and see if the issue comes up again, if that’s the recommended course of action.

hello nicolo,

fixed clock rates in order to ignore system level clock configuration.

we may still need to understand the error logs.
you may try setting up a terminal to keep gathering the logs. i.e. $ dmesg --follow.
please share complete failure logs with respect to the “pure virtual method called” crash.

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