A user-developed shared library file being randomly closed by the Argus application?

[Shrihari33]

Hello everyone, I hope you are doing extremely well.

I have built a shared library that intercepts the kernel level “ioctl” calls to analyse the flow of calls as a beginner into driver programming. The problem that I have is with loading that library before running any argus samples that come shipped with the Jetson board.

The log file is opened (visible by the “FILE OPENED”), but log file is deliberately closed before anything even begins, but the calls made by the application are indeed being passed through my intercept function (verifiable by the “Log file not Found” message that gets printed).
But I am not sure why the log file is being abruptly closed in the beginning of the whole process itself. Is there a clean-up process that is making the file descriptors go away, or is there a problem with my library because I have NOT made my log file thread safe. I tried running the ‘oneShot’ and ‘yuvOneShot’ applications, but both failed with the logging, although they do capture an image.

My log file does open, but gets closed immediately after I get the message “Wrote file: argus_oneShot.jpg”. Although the further messages that indicate the “not being able to write the log to the ioctl made” are only visible after the above “Wrote” message. There is a significant delay in the calling of the destructor of my shared library, which makes me question what is actually happening.
The bad file descriptor error also is unclear to me, and whether or not is it related to my issue.

I think that the argus application internally is spawning a new process, which is interfering with my file descriptor; leading to undefined behaviour. But this is just a mere speculation.

My log file works perfectly on my x86 host machine with both, direct V4L2 calls, as well as with GStreamer.
The output that I get if I run the sample on the Jetson is attached below. I would appreciate any help in debugging this, thanks!

[ShaneCCC]

Maybe try build the argus sample code by below command to confirm.
If disable multiprocess working that could be the connect the argus_socket cause the problem.

cmake -DDISABLE_MULTIPROCESS=ON ..

[Shrihari33]

Hello ShaneCCC,

I did try that, but it doesn’t seem to be working as there is still a notice of thread libraries being interrupting the code flow somehow (as you can view in the below gdb trace).

After debugging, we realised that our library, written in C++ style File operations was not portable. We switched to C style File I/O, and it doesn’t SIGSEGV now. But, we have other problems that we encounter, which are:

• Even though my library’s C style attribute constructor runs and successfully opens the log file (as visible in the below image of gdb trace), the application stops at one specific IOCTL call that is not known to us as of now.

• The error that we get is “log file not open”, which is only printed when the application is redirected to our ioctl call, and then it happens to be the case that our log file was closed. So, in this tiny moment, some process closed this previously opened log file.
  The error follows with the below text:

"Error: Can't initialize nvrm channel
Couldn't create ddkvic Session: Cannot allocate memory
nvbuf_utils: Could not create Default NvBufferSession
[Inferior 1 (process 9715) exited with code 0377]

The application we are running is the argus sample yuv_oneShot. It does run perfectly ok (with some warning and errors initially), but it does stream the stuff perfectly.
It is only when we load our library that we get this error.

This image show-cases the error we mentioned we get when loading our library. We are sure that this is only called when the application / runtime is calling ioctl, and it is being redirected to us because, we only get the errors above printed, after the “log file not open” gets printed. This print statement is called by my library’s ioctl in case the log file was closed (which we don’t know why was it closed).

My library’s attribute ctor should also print “Sensor Driver Debug Recorder Startup” and “FILE OPENED” to the console, but it ONLY prints this when ran with GDB (as shown below).

Also, I tried to add a break point at the first ioctl call that is made, and we ended up receiving the “request” parameter of the value 3222292494. This call is trying to access address of “0xff …”, which is what is confusing the thing I believe. Could you let us know where we can find the defines for these?

I would truly appreciate your help in debugging this. Thank you so much ShaneCCC!

UPDATE:
ShaneCCC, I was able to log properly but only by forcing the log file to be reopened in case it was closed in my ioctl call (which is not an expected, normal behaviour). I still am very curious to know why the log file was even closed in the first place, and by who. Thanks!