12-30-2020 02:46 PM - edited 12-30-2020 03:38 PM
Use case: have 7820R, 7858R, 7975R FPGA cards being accessed currently under CentOS 7 via the FPGA C API (not using LabVIEW/CVI).
So I have a complex C program that is multithreaded, and is working fine accessing these three FPGA cards. I have one thread per card for handling interrupts from the FPGA fabric, and this works fine.
I have a cleanup function that I have registered with atexit() (formerly registered with on_exit(), but this function is apparently deprecated). The cleanup function has been working for years in the field in a mission critical application. When I added support for the FPGA C interface, any time I call into the FPGA C API from the cleanup function (triggered by exit(0)), I get a segmentation fault. If I comment out any C API call in the cleanup function, the program proceeds until the next API call and seg faults. The subroutines and FPGA API calls I'm doing work perfectly fine in the rest of the program, and the program can run all day without a problem accessing the FPGA C API calls and the FPGA fabric on the three cards. The gdb debugger seems to show the program stopping down in the NI libraries after the cleanup function is triggered by exit(0).
So, the question is when the function registered with atexit is triggered by exit(0), is the underlying NI subsystem getting sent some signal or something happening that is causing FPGA C API function calls to fail? At this point I'm thinking I need to avoid using atexit().
Edit: if I don't register the cleanup function with atexit and call the cleanup function directly, there's no segmentation fault and the FPGA C API calls seem to operate normally.
Lorn Hartshorn
Electrical and Software Engineer
Amentum
02-16-2021 10:26 AM
If you are still interested in this, could you post some minimal code that reproduces the problem?