How can I find where the error occurs?
In C language, the return value means what error occurs,
such as failure to open file or memory allocation.
There is no information where the error occurs.
For example, function 'foo' calls A,B,C,D.
If foo returns an error value, it might be return value of A or B or C or D.
I cannot find what function returns error.
I have to run debugger or add some codes to find what function returns error.
Yes, you'll have to use a debugger or add extra code to display some output. Also, make sure you look at the pre-conditions for the function you call (if there are any) - make sure that you obey what it demands before calling it.
I think you've answered your question, you need to use a debugger to find out.
Maybe add some breakpoint, look if the error occurs always or only sometimes, and in the same place.
C library functions like fopen() set errno to give you a bit more diagnostic information. You could use a similar strategy. But if you don't program in some way of getting extra information out like that, you are stuck with the debugger.
Design an appropriate error handling that provides the informations you need. Then write your functions around this design. Using the return values is just one of many possibilities to do this, but obviously not enough for your specific requirements.
What error occurs is a clue for where it occurs: if A can return only error #5, B only #42, C only #3 and D only #56, whenever foo returns #5, you know that it comes from A.
If error codes overlap over different functions, you can get other clues from your inputs and your outputs: if D either displays a message or issues an error #5, whenever foo returns #5 and the message gets displayed, you know that error comes from A.
If error code, inputs and output are not enough to retrieve error location, you have to increase observability of your program. Some solutions are:
add debug info and use a debugger
add logs that you can activate or inhibit at will
select unique error codes so that what error occurs identifies where it occurs as well
Related
Assume I have a long call-stack. My upper level function returns a error code such as ERROR_INTERNAL(it's int type). I can see many return ERROR_INTERNAL; in source code, but don't know which one generate current error.
I debug it with gdb, and want to quickly know which down-level function is the first one to throw this error. I'm not familiar with the code, and I don't have time to delve into it.
Anyone who knows how to use gdb functions such as conditional breakpoints to locate the function ?
here my output, I don't understand the hex "0xe8" and "0x7f8c783ac74d";
/home/roroco/Dropbox/rbs/ro_article/c/ro_helper_article.so(get_article_n2+0xe8) [0x7f8c783ac74d]
here is full output
It looks like you've caused (or, rather, a plugin caused) ruby to segfault. This normally means that you've attempted to access memory outside of your designated bounds - basically, your program did something really, really weird. The line you specifically picked out is actually a C library - the .so extension means "static object," and is linked into the main ruby executable. The information it's providing you with tells you where the error originated - however, most production libraries do not contain information such as "file names" and "line numbers". Instead, they contain a list of symbols. In your case, it's telling you exactly where, in the static object, an error originated - exactly 0xe8 bytes after the get_article_n2 symbol - or, at the address 0x7f8c783ac74d.
So now you have a few options.
You can poke around blindly in your source code (I'm assuming you wrote the library that is in error here, since it seems that's what you're testing) and try and guess where the segfault originated. You already know that it's in the function get_article_n2, considering the error originated after that symbol.
You can disassemble the static object to see the specific instruction that caused the error, and then attempt to map it to the source.
You can enable debugging, and have your build system output file names and line numbers so you know what you're looking at. (disclaimer: I'm not sure if this will work; it doesn't look like you're emitting debug information to me, but I'm not sure if you are; and even if you would be, I'm not sure it would be used to output. However, this seems the easiest course of action.).
I am using get_nproc() and get_nprocs_conf() top get number of online and all processor cores present in my machine.
How do I check for errors with these functions. Any specific error values?
Do they even notify of errors ? not sure.
I would really like to check for error with the call as my program would depend on the returned values a lot.
FYI - As these functions are available from GNU library I prefer these over
sysconf (_SC_NPROCESSORS_ONLN) and sysconf (_SC_NPROCESSORS_CONF)
so basically I want to avoid including extra file
Also, I see that these are declared in -- sys/sysinfo.h but wasn't able to find the definition. Any idea on where can I get that ?
get_nprocs and get_nprocs_conf are GNU extensions which are not documented to return errors. These functions are very unlikely to fail because they parse interfaces provided by the kernel in /sys or /proc. Still, failures can happen, either due to a kernel misconfiguration, a bug in the parser, or (most likely) a lack of resources causing open() to fail. In that case, the current implementation of both functions returns 1 without setting an error flag.
In other words, you are expected to use the return value as if the functions cannot fail. Since the fallback value returned in the unlikely case of error is fairly reasonable, doing just that does not seem like it will cause problems.
Here's a copy of the appropriate manual page: http://www.unix.com/man-page/linux/3/get_nprocs/
No error indicators are documented, though it follows from the function descriptions that if either function ever returns a value less than 1 then the function must have failed (else the function could not have run).
I wanted to show my students how to use regular expresions. As they are learn programming in C, I thought it would be the best to use regex.h from GnuWin32 (http://gnuwin32.sourceforge.net/packages/regex.htm). As an example I tried to run http://www.peope.net/old/regex.html programm, but it causes an exception on the variable holding the regular expression at runtime . The precise error message is:
Run-Time Check Failure #2 – Stack around the variable 'regex' was corrupted
The courius thing is that the example itself is running properly and the regex functions seems to work properly. The error happens after all the important things are over at the point where main() wants to return.
Has anybody an idea of why this error occurs? Could the 64-Bit System I'm using be part of the problem?
Thanks for any advice!
I have been thinking about the difficulty incurred with C error handling.. like who actually does
if(printf("hello world")==-1){exit(1);}
But you break common standards by not doing such verbose, and usually useless coding. Well what if you had a wrapper around the libc? like so you could do something like..
//main...
error_catchall(my_errors);
printf("hello world"); //this will automatically call my_errors on an error of printf
ignore=1; //this makes it so the function will return like normal and we can check error values ourself
if(fopen.... //we want to know if the file opened or not and handle it ourself.
}
int my_errors(){
if(ignore==0){
_exit(1); //exit if we aren't handling this error by flagging ignore
}
return 0;
//this is called when there is an error anywhere in the libc
}
...
I am considering making such a wrapper as I am synthesizing my own BSD licensed libc(so I already have to touch the untouchable..), but I would like to know what people think about it..
would this actually work in real life and be more useful than returning -1?
during this years I've seen several attempts to mimics try/catch in ANSI C:
http://simgrid.gforge.inria.fr/doc/group__XBT__ex.html
http://llg.cubic.org/trycatch/
I think that try/catch approach is more simple than your.
But how would you be able to catch the error when it was expected? For example I might expect a file open to fail and want to deal with it in code instead of the generic error catcher.
To do this you would need two versions of every function. One that trapped errors and one the returns errors.
I did something like this long ago without modifying the library. I just created wrapper functions for common calls that did error checking. So my errchk_malloc call checked the return and raised an error if the allocation failed. Then I just used this version everywhere in place of the built in malloc.
if the goal is to exit cleanly as soon as you encounter an error that's ok... but if you want to do a minimum of error recovery, i can't see how your approach is useful...
To avoid this kind of problem, I sometimes use LD_PRELOAD_PATH to integrate my error management (only for my own projects since this is not a really good practice...)
Do you really want to change the standard behaviors of your LIBC ? You could add a few extensions around common functions.
For example, Gnome uses g_malloc and g_try_malloc. The former will abort on failure while the later will simply yield a null-pointer like malloc.