Here is the sha1sum :
sha1sum /usr/lib/aarch64-linux-gnu/tegra/libcuda.so.1
7baf0e02aa991e673cc493f5388634b5554de7e6 /usr/lib/aarch64-linux-gnu/tegra/libcuda.so.1
Hi Honey_Patouceul,
What is the failure rate you observe? On r28.1/TX2, I try to run
$ export DISPLAY=:0
$ gst-launch-1.0 -ev nvcamerasrc ! 'video/x-raw(memory:NVMM), width=1280, height=720, format=NV12, framerate=120/1' ! nvivafilter customer-lib-name="libnvsample_cudaprocess.so" cuda-process=true ! 'video/x-raw(memory:NVMM),format=RGBA' ! nvegltransform ! nveglglessink
and occasionally can see the crash. We will check further. It would be helpful if you can share a
consistent way to reproduce the issue. Thanks.
Hi DaneLLL,
I can reproduce it this way:
- Boot TX2
- Login with Ubuntu GUI as ubuntu or nvidia (no difference)
- Launch a terminal with dmesg --follow
- Launch another terminal.
- In second terminal, launch
export DISPLAY=:0
gst-launch-1.0 -ev nvcamerasrc ! 'video/x-raw(memory:NVMM), width=1280, height=720, format=NV12, framerate=120/1' ! fakesink
let it run for a few seconds and stop it with Ctl-C.
6. re-launch
gst-launch-1.0 -ev nvcamerasrc ! 'video/x-raw(memory:NVMM), width=1280, height=720, format=NV12, framerate=120/1' ! fakesink
let it run for a few seconds and stop it with Ctl-C.
On that second Ctl-C, the fault happens each time on my TX2.
After nvcamera-deamon has crashed and another instance has been restarted, then it no longer faults.
Not sure how much use it is going to be, but I found the location in libcuda.so.1.1 where this code exists. If you dump libcuda.so.1.1 like this:
objdump --disassemble libcuda.so.1.1
…the assembler you gave earlier starts at line 497692:
497692 272130: b9400042 ldr w2, [x2]
497693 272134: b9000022 str w2, [x1]
497694 272138: f9400802 ldr x2, [x0,#16]
497695 27213c: b9400442 ldr w2, [x2,#4]
497696 272140: b9000422 str w2, [x1,#4]
497697 272144: f9400802 ldr x2, [x0,#16]
497698 272148: b9400842 ldr w2, [x2,#8]
497699 27214c: b9000822 str w2, [x1,#8]
497700 272150: f9400802 ldr x2, [x0,#16]
497701 272154: 79401842 ldrh w2, [x2,#12]
497702 272158: 53003c42 uxth w2, w2
497703 27215c: 79001822 strh w2, [x1,#12]
I’m not positive about this, but a more detailed disassembly reveals this assembler probably exists within symbol “cuGLUnregisterBufferObject”. So cuGLUnregisterBufferObject is likely the point in the stack frame where the error occurs (there are a number of branch instructions so I don’t know which of the symbols between cuGLUnregisterBufferObject and this point might have been called). I would be very curious to see the actual stack frame with symbols of the source code during the error (stripped files are fun, but not a great debug tool) :P
Hi Honey_Patouceul, linuxdev,
Please try attached nvcamera-daemon on r28.1
nvcamera-daemon.txt (35.2 KB)
For me this new nvcamera-daemon version results in:
$ export DISPLAY=:0
$ export GST_DEBUG=nvivafilter:4
$ gst-launch-1.0 -ev nvcamerasrc ! 'video/x-raw(memory:NVMM), width=1280, height=720, format=NV12, framerate=120/1' ! fakesink
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
Setting pipeline to NULL ...
Freeing pipeline ...
This is the same result using both fakesink and the original camera commands from earlier in this forum thread.
Hi linuxdev, we don’t see the failure on r28.1/TX2 with nvcamera-daemon replaced.
What is the failure rate in your trials?
This might not be the cause in your case, but I faced this after saving the new binary, because I had forgotten to set execution permission.
All went fine after
chmod a+x /usr/sbin/nvcamera-daemon
The nvcamera-daemon service logs into /var/log/syslog. Any trace there ?
You were right…such a simple thing I should have thought of that! The patched nvcamera-daemon does work.