CerebusOSS/CereLink

testOpen failed (-26)!

Closed this issue · 5 comments

jsv13 commented

Hi all,
I'm working on a Ubuntu 16.04 machine, I've compiled cerelink successfully and can connect to nPlayServer running on a remove Windows machine.
However, when I try to connect to nPlayServer from the same Ubuntu machine with a different user account I get a library memory allocation error.
Output from testcbsdk is:

Initializing Cerebus real-time interface 6.05.19.00 (protocol cb3.10)...
Library memory allocation error
testOpen failed (-26)!
Real-time interface already closed
testClose succeeded

Seems weird to me, that this is somehow user-specific. Any idea?
Thanks !

I have never tried with another user, it could be a permission issue when trying to access the file lock. A file lock is used to control access. Try with sudo if it worked, it could be the issue here.

jsv13 commented

thanks! yes, with sudo it works. How can I make it work without sudo?

There are multiple users that need to share one machine, and I do not want to give sudo rights to every one.

You can specify more parameters when running the open (like ip, ...) then it should not try to open the lock file and will use those information to connect.

jsv13 commented

The problem with the user rights seems to be twofold:

  1. Qt QShareMemorycreates user specific temporary files in /tmp but after the end of the execution not all of them are deleted. After closing the connection qipc_sharedmemory_... files are deleted, but qipc_systemsem_... are not. If another user tries to use cbsdk QShareMemory​ will fail, because it tries to access the same files.
  1. The same is true for cbSharedDataMutex.lock​.
    Depending on the reason the connection to nPlayServer fails, it may or may not be deleted.

Do you know of any easy way to force QShareMemory to use specific filenames for the temporary files it creates? They could be different for every user and then the problem could be avoided.

I have long wanted to get rid of QSharedMemory it seems to be broken in most scenarios, and has limited memory on OSX. Should instead use something else.

A hacky way to fix per-user should be easy, should just prepend the uid to the name perhaps, then it will be unique per user