What's the best practice for exiting C code on discovery of an error back to R? Package guidance says don't use exit(), which makes sense (as you kill everything), but how do you exit to R and indicate an error has occurred. Obviously you could have an error flag in the return vector, but is there a better way?
You're looking for error(). It's described in Section 6.2 of Writing R Extensions... and you should listen to your subconscious more often. ;-)
Related
I have few questions as below regarding Hiredis for C:
I read somewhere that hiredis does not do connection pooling. Is there any library available for hiredis which does connection pooling or may be an alternative to hiredis which has connection pooling.
For other question I'll give the background below:
In the code I plan to use the same context through out until the application stops, don't know is this the correct way and what are the complications of doing this. Please correct me if I am doing anything wrong. The way I want to do is, the app forks few child once started. I will create the context in the child initialization and use it for all the requests the process serves. Also, I can check the reply of redisCommand and try to reconnect as:
reply = redisCommand(c,"set %s %s","key","value");
if(reply == NULL)
{
printf("Connection error.\n");
c = redisConnect(hostname,port);
// checks
}
**Q:**How can I check if context is still valid, means the connection is not lost? I see REDIS_CONNECTED in hiredis.h but not sure this is what can tell this. I printed this variable after creating context which printed 2 and then I stopped the DB but still it printed 2 and program segfaulted. Does hiredis handles reconnection.
EDIT:
I am no expert in C, I would appreciate if I can get some useful links from where I can learn how to create and use connection pools in C.
Thanks
I am trying to use SCIF inter-process communication on Xeon Phi. My program has two processes, one process writes data to another process using scif_writeto. Currently, I encountered an error " No device or address" for the scif_writeto API. I checked that the end point is set up correct, the offset is also returned correctly. I don't have any idea about what's going wrong here. Is there any good suggestion to debug this issue?
In user mode scif_writeto() returns -1 in case of fail and set errno to indicate the error. Possible errors are described in scif.h.
You could check the errno to debug your problem.
For example, if it failed to invoke msgsnd/msgrcv:
How to handle the errno – what is the best way?
What principle is applying to business product?
Shall I have to cover all of them?
What kinds of error must be handled? Do I have to write a signal handler for EINTR or something like this?
Here's my straw-man code:
RetVal = msgrcv(... );
if( RetVal == -1 )
{
switch (errno)
{
case E2BIG:
...
case EAGAIN:
...
case EFAULT:
...
case EIDRM:
...
case EINTR:
...
case EINVAL:
...
case ENOMEM:
...
default:
...
}
This depends on the coding standards you want to apply, and how you might reasonably respond to the failures.
You should always check errors, but you might commonly only handle one or two of them such as EINTR. I would at least try to print some kind of diagnostic last-gasp message before violently exiting in the case of unexpected errors.
The more critical the software, the more carefuly-designed it needs to be, and more comprehensive error handling is part of that.
Since your tags are "C" and "Linux" I assume you're using GCC, in which case have a look at the handy %m in printf.
Obviously this too simple for some cases, but until your program is finished something like this is a good stub to have.
if(RetVal == -1) {
perror("message receive");
exit(1);
}
Typically, one only looks at the exact error if a specific recovery is called for in that case. Until you have some code that you need to make conditional on exactly the type of error, you should simply decide between...
Silently ignore the error
Warn, and then continue
Complain, and then exit
See also...
the nonstandard-but-useful err(3).
setjmp, longjmp, sigsetjmp, et al
It depends on your code and what you can do (similar to exception) and what error you have received. For example EAGAIN is not a strictly an error (it denotes that you tried non-blocking operation and it would block).
If it is a quick program you may do nothing (say - you just playing with API). If it has GUI it might display a message (say "disk is full" or "cannot connect to network") etc.
If the question had an ultimate answer there would be no need for errno - system call could do it as well.
The basic Linux system calls almost universally return -1 on error, and 0 or positive value on success. Also, the errno is set to one of the predefined values. So, checking failure of system calls is pretty easy and should be done consistently. Checking the errno for what type of error occurs should be done for the errors you can handle in your program itself. For other errors, it is best to inform the user that he made an error and notify him with the error. The strerror() in the string.h takes erroro as the parameter and returns a pointer to string describing the error.
#include<string.h>
char* strerror(int errno);
After telling the error, it is on the severity of the error whether to continut running the program or exit the program by
exit(1);
I am using the library Function ConnectToTCPServer. This function times out when the host is not reachable. In that case the application crashes with the following error:
"NON-FATAL RUN-TIME ERROR: "MyClient.c", line 93, col 15, thread id 0x000017F0: Library function error (return value == -11 [0xfffffff5]). Timeout error"
The Errorcode 11 is a Timeout error, so this could happen quite often in my application - however the application crashes - i would like to catch this error rather than having my application crash.
How can i catch this runtime error in Ansi C90?
EDIT:
Here is a Codesnippet of the current use:
ConnectToTCPServer(&srvHandle, srvPort, srvName, HPMClientCb, answer, timeout);
with
int HPMClientCb(UINT handle, int xType, int errCode, void *transData){
printf("This was never printed\n");
return errCode;
}
The Callbackfunction is never called. My Server is not running, so ConnectToTCPServer will timeout. I would suspect that the callback is called - but it never is called.
EDIT 2: The Callback function is actually not called, the Returnvalue of ConnectToTCPServer contains the same error information. I think it might be a bug that ConnectToTCPServer throws this error. I just need to catch it and bin it in C90. Any Ideas?
EDIT 3: I tested the Callbackfunction, on the rare occaision that my server is online the callback function is actually called - this does not help though because the callback is not called when an error occurs.
Looking in NI documentation, I see this:
"Library error breakpoints -- You can set an option to break program execution whenever a LabWindows/CVI library function returns an error during run time. "
I would speculate they have a debug option to cause the program to stop on run-time errors, which you need to disable in configuration, in compile time or in run-time.
My first guess would have been configuration value or compilation flag, but this is the only option I found, which is a run-time option:
// If debugging is enabled, this function directs LabWindows/CVI not
// to display a run-time error dialog box when a National Instruments
// library function reports an error.
DisableBreakOnLibraryErrors();
Say if it helped.
Theres no such thing as a general case of "catching" an error (or an 'exception') in standard C. Thats up to your library to decide what to do with it. Likely its logging its state and then simply calling abort(). In Unix, that signals SIGABRT which can be handled and not just exit()ed. Or their library may just be logging and then calling exit().
You could run your application under a utility like strace to see what system calls are being performed and what signals are being asserted.
I'd work with your vendor if you can't make any headway otherwise.
From the documentation, it seems you should get a call to your clientCallbackFunction when an error occurs. If you don't, you should edit your question to clarify that.
I'm not sure I understand you.
I looked at the documentation for the library function ConnectToTCPServer(). It returns an int; 0 means success, negative numbers are the error codes.
EDIT: Here is a Codesnippet of the
current use:
ConnectToTCPServer(&srvHandle, srvPort, srvName, HPMClientCb, answer, timeout);
If that's really the current use, you don't seem to be trying to tell whether ConnectToTCPServer() succeeds. To do that, you'd need
int err_code;
...
err_code = ConnectToTCPServer(&srvHandle, srvPort, srvName, HPMClientCb, answer, timeout);
and then test err_code.
The documentation for ConnectToTCPServer()implies that your callback function won't be called unless there's a message from a TCP server. No server, no message. In that case,
ConnectToTCPServer() should return a negative number.
You should check the return value of ConnectToTCPServer().
Finding a negative number there, you should do something sensible.
Did I understand the documentation correctly?
Normally, you should be able to simply check the return value. The fact that your application exits implies that something is already catching the error and asserting (or something similar). Without seeing any context (i.e. code demonstrating how you're using this function), it's difficult to be any more precise.
The documentation states that ConnectToTCPServer will return the error code. The callback is only called if the connection is established, disconnected or when there is data ready to be read.
The message you get states that the error is NON-FATAL, hence it shouldn't abort. If you're sure the code doesn't abort later it seems indeed like a bug in the library.
I'm not familiar with CVI, but there might be a (compile-/runtime-) option to abort even on non-fatal errors (for debugging purposes). If you can reproduce this in a minimal example you should report it to NI.
I'm learning my way about socket programming in C (referring to Beej).
Here is a simple multi-user chat server i'm trying to implement:
http://pastebin.com/gDzd0WqP
On runtime, it gives Bus Error. It's coming from the lines 68-78.
Help me trace the source of the problem?
in fact, WHY is my code even REACHING that particular region? I've just run the server. no clients have connected.. :#
ps - i know my code is highly unreliable (no error checks anywhere), but i WILL do that at a later stage, i just want to TEST the functionality of the code before implementing it in all it's glory ;)
line 81
msg[MSG_SIZE] = '\0';`
overruns your buffer. Make it
msg[MSG_SIZE - 1] = '\0';`
You also need to check the return value of all the calls that can fail, that's line 39,42,45,68 and 80
Edit: And if you'd checked for errors, likely you'd seen the accept() call fail, likely due to the socket not being in listen mode - that is, you're missing a call to listen()
Another thing to consider is that you can't necessarily copy fd_set variables by simple assignment. The only portable way to handle them is to regenerate the fd_set from scratch by looping over a list of active file descriptors each time.