cifXDriverInit segfaulting for different INIT options

[joelosw]

Hi, we are using HilscherCards in some of our projects.

As initialization of the driver we use (simplified, reproducable:)

    const char*  base_dir_=".";
    struct CIFX_LINUX_INIT init;
    init.init_options       = CIFX_DRIVER_INIT_AUTOSCAN;
    init.iCardNumber        = 0;
    init.fEnableCardLocking = 0;
    init.base_dir           = &base_dir_[0];
    init.poll_interval      = 0;
    init.poll_StackSize     = 0; 
    init.poll_schedpolicy   = 0;
    init.poll_priority      = 0;
    init.trace_level        = 255;
    init.user_card_cnt      = 0;
    init.user_cards         = NULL;
   cifXDriverInit(&init);

With libcifx 2.0 and Ubuntu 18.04(4.15) this worked great.
However, with libcifx 3.0 and Ubuntu 22.04(6.15) this initialization causes a segfault inside the call cifXDriverInit(&init):

This is reproducable with you api_cifx example, when exchanging the initialisation parameters to the above block.

Even if the initialization might not be correct (even though we think it should be) this should probably not segfault but throw an error instead?

[MTrensch-hilscher]

No problem here on a system running Kernel 5.15 compiled with gcc 12.2.0:

$ LD_LIBRARY_PATH=/usr/local/lib ./cifx_api

---------- Display Driver Version ----------
Driver Version: LinuxCIFXDrv V3.0.0, based on cifX Toolkit 2.8.0.1

 State = 0x00000000
----------------------------------------------------
---------- Board/Channel enumeration demo ----------
Found Board cifX0
 DeviceNumber : 1291101
 SerialNumber : 38886
 Board ID     : 0
 System Error : 0x00000000
 Channels     : 0
 DPM Size     : 65536
 State = 0x00000000
----------------------------------------------------
---------- System Device handling demo ----------
System Channel Info Block:
...

Are you mixing header files between 2.x and 3.x causing a different structure layout?

[joelosw]

Mhhm interesting.
I just verified that we are using the headers of cifx 3, which are present in this repository as well.
Is there any chance you could test the setup with Kernel 6.15, where the problem occurs for us?
Thanks for taking the time to investingate with us!

[MTrensch-hilscher]

I doubt is has something to do with the kernel version, but rather some other issue (possibly security).
As I don't have access to a development system right now and currently locked by other tasks, so it could take a while to set something up.

Maybe you should either strace the application or run it inside gdb and take a lock at the call stack (bt command).