Sorry for the delayed response to your question…
This is nothing to be really worried about. What happens is the following:
comes with a daemon executable that is intended to receive log messages and any binary can in fact send its log output to that daemon (the LogGUI program connects to the same daemon and receives that the daemon gathered and subsequently visualizes it).
The connection between the binary that emits log messages and the daemon is established by means of a named bit of shared memory (implemented based on the boost shared memory API)
The message you see is what is emitted if a binary fails to open that piece of shared memory.
Failure to open the shared memory block for initiating communication with the log daemon on the sender side usually means that the log daemon has not (fully) started yet and that the shared memory block is not yet available. Theoretically, an unclean exit of the log daemon could also lead to similar output - but of course unclean exits never occur, right? It could also mean that the daemon has been started with insufficient rights and failed to open the shared memory block (admin rights are needed for allocating a piece of named shared memory).
What consequences does this have? → not too many…
Your program will not be able to emit log messages to the log daemon, obviously. These messages are sometimes nice when trying to debug code, but at runtime they are usually not essential (at runtime they add considerable value only on the driver side)
You don’t need to worry about extra latencies or stalls in function calls: If no active log config is available, then no extra processing time is spent on logging (to the point that the binaries won’t even bother putting together the strings for logging…).
Thank you for the detailed description. So I should restart the service that is responsible for logging?
The problem is that the program I wrote won’t start because of the error and the programs like the CVB LoggingGui won’t start either.
A system reboot did nothing and a reinstallation of cvb did nothing either.
I am now reinstalling a new version of cvb.
Ok, then I got you wrong - I understood your (private) message yesterday to the effect that it basically works. In that case, the problem is definitely not the fact that libCVCore.dll cannot connect to the logging service - logging is strictly optional.
If the application fails to start/run properly then the first step towards diagnosing should probably be to find out which operation gave rise to the “C-API call failed” message that you saw. This message is emitted by the CVB++ API when a call into the underlying C-API failed but no additional error information is available. It is generated in _ c_exports/c_img.h on line 101 and 116 - for debugging purpose you could just emit functionName to std::cerr or std::cout to find out which call failed.
I solved the problem by rebuilding the kernel and then reinstalling the CVB software, but I didn’t make an image of the system where the error occurred, I wanted to solve it as quickly as possible, so I reinstalled everything.