in some functions I need to allocate memory with malloc() and have several if..else statements, like the pseudo-code illustrates:
allocate memory
if condition_1
do_stuff
if condition_2
do_more_stuff
else
error
else
error
free allocated memory
return
So I allocate memory at the beginning and it would freed if everything would work well. But currently the error functions only print an error message and exit the porgram. But as I have read often that not freeing memory although when the program exits and the OS handles normally handles the freeing afterwards, it no good style. How can I free the money in a lazy way? Do I have to write an error function that takes every pointer to the memory I have allocated that has to be freed,the pointery may be of different data types? Or should i put free(ptr) before calling the error function? An error function that takes an array of pointer with data type void and freeing than all, would do this the trick?
I have two solutions.
You can put a label where you put the call to free and error:
void function(void)
{
Memory *p = malloc(sizeof(*p));
if (condition_1) {
do_stuff();
if (condition_2) {
do_more_stuff();
} else {
goto err;
}
} else {
goto err;
}
free(p);
return;
err:
free(p);
error();
}
You can also use a flag to mark an error:
void function(void)
{
Memory *p = malloc(sizeof(*p));
bool err = false;
if (condition_1) {
do_stuff();
if (condition_2) {
do_more_stuff();
} else {
err = true;
}
} else {
err = true;
}
free(p);
if (err)
error();
}
I think that the second solution looks best in this case but both of them work equally well.
Don't use goto. Use a one-time while. Also, if you need an error flag, default it to true instead of false to save code:
...malloc...
err = 1;
do {
...
if <condition> break;
...
if <condition> break;
...
if <condition> break;
...
err = 0;
} while (0);
...free...
if (err) ...
From what I understand you care about freeing all the memory when you exit the program because of error but dont want to handle all the pointers manually.
Here is an interesting thought, write a function allocMemory that returns the result of malloc but also puts the pointer into a linked list, then freeMemory that removes it from the list, and finally release all function that iterates over the list and frees all the pointers.
Use the allocMemory and freeMomory function instead of malloc and free, and call the freeMemory function in case of error.
Related
void* password_cracker_thread(void* args) {
cracker_args* arg_struct = (cracker_args*) args;
md5hash* new_hash = malloc (sizeof(md5hash));
while(1)
{
char* password = fetch(arg_struct->in);
if(password == NULL )
{
deposit(arg_struct->out,NULL);
free(new_hash);
pthread_exit(NULL);
}
compute_hash(password,new_hash);
if(compare_hashes(new_hash,(md5hash**)arg_struct->hashes,arg_struct->num_hashes) != -1)
{
printf("VALID_PASS:%s \n",password);
deposit(arg_struct->out,password);
}else{
free(password);
}
}
}
This is a part of a program, where you get char* passwords from a ringbuffer, calculate md5 and compare them and push them into the next buffer if valid.
My problem is now, why can't I free those I don't need?
The whole program will stop if I try to and if I don't, I get memory leaks.
"You", and by this I mean your program, can only free() storage that was got from malloc()-and-friends, and only in the granularity it was got, and only once per chunk of storage.
In the code you show here, you're attempting to free() something got from fetch(). Since we can't see the definition of that function and you have not provided any documentation of it, our best guess is that
fetch() gives you a pointer to something other than a whole chunk
got from malloc()-et-al; and/or
some other part of the program not
shown here free()s the relevant chunk itself.
Is the following usage of pointers in functions call is a memory leak:
bson_t * parse_json(const char * json_fields){
bson_error_t error;
bson_t *bson_fields = bson_new_from_json((unsigned char *)json_fields, -1, &error);
if (!bson_fields) {
log_die("Error: %s\n", error.message);
} else {
return bson_fields;
}
log_die("Error: something bad happend in parse_columns");
return bson_fields; // this should never be reached ...
}
The following code works, but what happens to the pointer from parse_json here? Is this a memory leak?
bson_concat(fields, parse_json(json_fields));
The mongodb C-API offers the function bson_destory:
bson_destroy(fields);
I am wondering maybe it's better to explicitly free the memory of new_fields:
bson_t *new_fields = parse_json(json_fields);
bson_concat(fields, new_fields);
bson_destroy(new_fields);
While this example uses mongodb c-api, I am also trying to understand the general case.
some_type * pointer_returner(){
some_type *var;
...
return var;
}
do_something(pointer_retuner());
Is the call above causing a memory leak?
Yes, you need to call bson_destroy to deallocate your structure object it is no longer used.
From bson_destroy documentation:
The bson_destroy() function shall free an allocated bson_t structure.
This function should always be called when you are done with a bson_t unless otherwise specified.
For example,
I need to malloc two pieces of memory, so:
void *a = malloc (1);
if (!a)
return -1;
void *b = malloc (1);
if (!b)
{
free (a);
return -1;
}
Notice if the second malloc fails, I have to free "a" first. The problem is, this can be very messy if there are many such malloc's and error checking's, unless I use the notorious "goto" clause and carefully arrange the order of free's along with the labels:
void *a = malloc (1);
if (!a)
goto X;
void *b = malloc (1);
if (!b)
goto Y;
return 0; //normal exit
Y:
free (a);
X:
return -1;
Do you have any better solution to this situation? Thanks in advance.
We do like this:
void *a = NULL;
void *b = NULL;
void *c = NULL;
a = malloc(1);
if (!a) goto errorExit;
b = malloc(1);
if (!b) goto errorExit;
c = malloc(1);
if (!b) goto errorExit;
return 0;
errorExit:
//free a null pointer is safe.
free(a);
free(b);
free(c);
return -1;
Using goto is not a bad thing, in my opinion. Using it for resource cleanup is just right for it.
Source code as famous as the Linux kernel uses the technique.
Just don't use goto to go backwards. That leads to disaster and confusion. Only jump forward is my recommendation.
As previously mentioned by Zan Lynx use goto statement.
You can also alloc larger chunk of memory for further use.
Or you can invest your time to develop something like memory pool.
Or do this.
void *a,*b;
char * p = malloc(2);
if (!p) return -1;
a = p;
b = p+1;
I think OOP techniques could give you a nice and clean solution to this problem:
typedef struct {
void *a;
void *b;
} MyObj;
void delete_MyObj(MyObj* obj)
{
if (obj) {
if (obj->a)
free(obj->a);
if (obj->b)
free(obj->b);
free(obj);
}
}
MyObj* new_MyObj()
{
MyObj* obj = (MyObj*)malloc(sizeof(MyObj));
if (!obj) return NULL;
memset(obj, 0, sizeof(MyObj));
obj->a = malloc(1);
obj->b = malloc(1);
if (!obj->a || !obj->b) {
delete_MyObj(obj);
return 0;
}
return obj;
}
int main()
{
MyObj* obj = new_MyObj();
if (obj) {
/* use obj */
delete_MyObj(obj);
}
}
There's nothing really wrong with your goto code IMO (I'd use more verbose labels).
In this case though, the goto statements you've written create exactly the same structure as reversing the ifs.
That is, a conditional forward goto that doesn't leave any scope does exactly the same as an if statement with no else. The difference is that the goto happens not to leave scope, whereas the if is constrained not to leave scope. That's why the if is usually easier to read: the reader has more clues up front.
void *a = malloc (1);
if (a) {
void *b = malloc (1);
if (b) {
return 0; //normal exit
}
free(a);
}
return -1;
For a couple of levels this is OK, although taken too far you get "arrow code" with too many levels of indentation. That becomes unreadable for entirely different reasons.
Use a garbage collector like boehmgc.
It works, it's easy to use, there is no slowdown contrary to common opinion.
https://en.wikipedia.org/wiki/Boehm_garbage_collector
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Depending on the platform / context your application is running, continuing after malloc() is returning NULL may not make much sense anymore.
So in many cases, a simple
if (!a)
catastrophic_failure_bail_out();
might be the most sensible solution and keep the code clean and readable.
I'm trying to write a function in C to solve a math problem. In that function, there are several steps, and each step needs to allocate some memory with the size depending on the calculation results in previous steps (so I can't allocate them all at the beginning of the function). The pseudo code looks like:
int func(){
int *p1, *p2, *p3, *p4;
...
p1 = malloc(...);
if(!p1){
return -1; //fail in step 1
}
...
p2 = malloc(...);
if(!p2){
free(p1);
return -2; //fail in step 2
}
...
p3 = malloc(...);
if(!p3){
free(p1);
free(p2);
return -3; //fail in step 3
}
...
p4 = malloc(...);
if(!p4){
free(p1);
free(p2);
free(p3); /* I have to write too many "free"s here! */
return -4; //fail in step 4
}
...
free(p1);
free(p2);
free(p3);
free(p4);
return 0; //normal exit
}
The above way to handle malloc failures is so ugly. Thus, I do it in the following way:
int func(){
int *p1=NULL, *p2=NULL, *p3=NULL, *p4=NULL;
int retCode=0;
...
/* other "malloc"s and "if" blocks here */
...
p3 = malloc(...);
if(!p3){
retCode = -3; //fail in step 3
goto FREE_ALL_EXIT;
}
...
p4 = malloc(...);
if(!p4){
retCode = -4; //fail in step 4
goto FREE_ALL_EXIT;
}
...
FREE_ALL_EXIT:
free(p1);
free(p2);
free(p3);
free(p4);
return retCode; //normal exit
}
Although I believe it's more brief, clear, and beautiful now, my team mate is still strongly against the use of 'goto'. And he suggested the following method:
int func(){
int *p1=NULL, *p2=NULL, *p3=NULL, *p4=NULL;
int retCode=0;
...
do{
/* other "malloc"s and "if" blocks here */
p4 = malloc(...);
if(!p4){
retCode = -4; //fail in step 4
break;
}
...
}while(0);
free(p1);
free(p2);
free(p3);
free(p4);
return retCode; //normal exit
}
Hmmm, it seems a way to avoid the use of 'goto', but this way increases indents, which makes the code ugly.
So my question is, is there any other method to handle many 'malloc' failures in a good code style? Thank you all.
goto in this case is legitimate. I see no particular advantage to the do{}while(0) block as its less obvious what pattern it is following.
First of all, there's nothing wrong with goto—this is a perfectly legitimate use of goto. The do { ... } while(0) with break statements are just gotos in disguise, and it only serves to obfuscate the code. Gotos are really the best solution in this case.
Another option is to put a wrapper around malloc (e.g. call it xmalloc) which kills the program if malloc fails. For example:
void *xmalloc(size_t size)
{
void *mem = malloc(size);
if(mem == NULL)
{
fprintf(stderr, "Out of memory trying to malloc %zu bytes!\n", size);
abort();
}
return mem;
}
Then use xmalloc everywhere in place of malloc, and you no longer need to check the return value, since it will return a valid pointer if it returns at all. But of course, this is only usable if you want allocation failures to be an unrecoverable failure. If you want to be able to recover, then you really do need to check the result of every allocation (though honestly, you'll probably have another failure very soon after).
Ask your teammate how he would re-write this sort of code:
if (!grabResource1()) goto res1failed;
if (!grabResource2()) goto res2failed;
if (!grabResource3()) goto res3failed;
(do stuff)
res3failed:
releaseResource2();
res2failed:
releaseResource1();
res1failed:
return;
And ask how he would generalize it to n resources. (Here, "grabbing a resource" could mean locking a mutex, opening a file, allocating memory, etc. The "free on NULL is OK" hack does not solve everything...)
Here, the alternative to goto is to create a chain of nested functions: Grab a resource, call a function that grabs another resource and calls another function that grabs a resource and calls another function... When a function fails, its caller can free its resource and return failure, so the releasing happens as the stack unwinds. But do you really think this is easier to read than the gotos?
(Aside: C++ has constructors, destructors, and the RAII idiom to handle this sort of thing. But in C, this is the one case where goto is clearly the right answer, IMO.)
There's nothing wrong with goto in error handling and there's actually no code difference between using a do { ... } while(0); with breaks; instead of goto (since they're both jmp instructions). I would say that seems normal. One thing you could do that is shorter is create an array of int * types and iterate through while calling malloc. If one fails free the ones that are non-null and return an error code. This is the cleanest way I can think of so something like
int *arr[4];
unsigned int i;
for (i = 0; i < 4; ++i)
if (!(arr[i] = malloc(sizeof(int))) {
retCode = -(i + 1); //or w/e error
break;
}
if (errorCode)
for (i = 0; i < 4; i++)
if (arr[i])
free(arr[i]);
else
break;
or something along those lines (used brain compiler for this so I might be wrong)
Not only does this shorten your code but also avoids goto's (which I don't see anything wrong with) so you and your teammate can both be happy :D
David Hanson wrote the book C Interfaces and Implementations: Techniques for Creating Reusable Software. His Mem interface provides functions that are "similar to those in the standard C library, but they don't accept zero sizes and never return null pointers." The source code includes a production implementation and a checking implementation.
He also implements an Arena interface. The Arena interface releases you from the obligation to call free() for every malloc(). Instead, there's just a single call to free the entire arena.
CII source code
If an allocation fails, simply assign the error code as normal. conditionalize each malloc like so:
if (retCode < 0) malloc...
and then at the end of your code, add this:
int * p_array[] = { p1, p2, p3, p4};
for (int x = -retCode + 1; x >= 0; x-- )
{
free(p_array[x]);
}
Getting back in to some C work.
Many of my functions look like this:
int err = do_something(arg1, arg2, arg3, &result);
With the intent the result gets populated by the function, and the return value is the status of the call.
The darkside is you get something naive like this:
int err = func1(...);
if (!err) {
err = func2(...);
if (!err) {
err = func3(...);
}
}
return err;
I could macro it I suppose:
#define ERR(x) if (!err) { err = (x) }
int err = 0;
ERR(func1(...));
ERR(func2(...));
ERR(func3(...));
return err;
But that only works if I'm chaining function calls, vs doing other work.
Obviously Java, C#, C++ have exceptions that work very well for these kinds of things.
I'm just curious what other folks do and how other folks do error handling in their C programs nowadays.
If you have resources that need to be released at the end, then sometimes the old trusty goto can be handy!
int
major_func(size_t len)
{
int err;
char *buf;
buf = malloc(len);
if (err = minor_func1(buf))
goto major_func_end;
if (err = minor_func2(buf))
goto major_func_end;
if (err = minor_func3(buf))
goto major_func_end;
major_func_end:
free(buf);
return err;
}
Two typical patterns:
int major_func()
{
int err = 0;
if (err = minor_func1()) return err;
if (err = minor_func2()) return err;
if (err = minor_func3()) return err;
return 0;
}
int other_idea()
{
int err = minor_func1();
if (!err)
err = minor_func2();
if (!err)
err = minor_func3();
return err;
}
void main_func()
{
int err = major_func();
if (err)
{
show_err();
return;
}
happy_happy_joy_joy();
err = other_idea();
if (err)
{
show_err();
return;
}
happy_happy_joy_joy();
}
What are you doing in the else statements? If nothing, try this:
int err = func1(...);
if (err) {
return err;
}
err = func2(...);
if (err) {
return err;
}
err = func3(...);
return err;
This way you're short-circuiting the entire function, not even bothering with the following function calls.
EDIT
Going back and reading again, I realize that it doesn't matter what you do in your else statements. That sort of code can easily go immediately after the if blocks.
If error codes are boolean, then try the simpler code below:
return func1() && func2() && func3()
One approach which has been taken by OpenGL is to not return errors from functions at all but rather present an error state which can be examined after the function call. One nice thing about this approach is that when you have a function which you actually want to return something other than an error code, you can handle errors in the same way. Another thing which is nice about this is that if a user wants to call a number of functions and only succeed if all of them were successful, you can check for errors after the x amount of calls.
/* call a number of functions which may error.. */
glMatrixMode(GL_MODELVIEW);
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glEnable(GL_TEXTURE_2D);
/* ...check for errors */
if ((error = glGetError()) != GL_NO_ERROR) {
if (error == GL_INVALID_VALUE)
printf("error: invalid value creating view");
else if (error == GL_INVALID_OPERATION)
printf("error: invalid operation creating view");
else if (error == GL_OUT_OF_MEMORY)
printf("error: out of memory creating view");
}
Others have suggested good ideas. Here're the idioms I've seen
int err;
...
err = foo(...);
if (err)
return err;
...
You could macro this out to something like
#define dERR int err=0
#define CALL err =
#define CHECK do { if (err) return err } while(0)
...
void my_func(void) {
dERR;
...
CALL foo(...);
CHECK;
or, if you're feeling really motivated, fiddle with CALL and CHECK so they can be used like
CALL foo(...) CHECK;
or
CALL( foo(...) );
--
Often, functions which need to do cleanup on exit (e.g. free memory) are written like this:
int do_something_complicated(...) {
...
err = first_thing();
if (err)
goto err_out;
buffer = malloc(...);
if (buffer == NULL)
goto err_out
err = another_complicated(...);
if (err)
goto err_out_free;
...
err_out_free:
free(buffer);
err_out:
return err; /* err might be zero */
}
You could use that pattern, or try to simplify it with macros.
--
Finally, if you're feeling /really/ motivated, you can use setjmp/longjmp.
int main(int argc, char *argv[]) {
jmp_buf on_error;
int err;
if (err = setjmp(on_error)) {
/* error occurred, error code in err */
return 1;
} else {
actual_code(..., on_error);
return 0;
}
}
void actual_code(..., jmp_buf on_error) {
...
if (err)
longjmp(on_error, err);
}
Essentially, a declaration of a new jmp_buf and a setjmp function as setting up a try block. The case where setjmp returns non-zero is your catch, and calling longjmp is your throw. I wrote this with passing the jmp_buf around in case you want nested handlers (e.g. if you need to free stuff before signaling an error); if you don't need that, feel free to declare err and the jmp_buf as globals.
Alternately, you could use macros to simply the argument passing around. I'd suggest the way Perl's implementation does it:
#define pERR jmp_buf _err_handler
#define aERR _err_handler
#define HANDLE_ERRORS do { jmp_buf _err_handler; int err = setjmp(_err_handler);
#define END_HANDLE while(0)
#define TRY if (! err)
#define CATCH else
#define THROW(e) longjmp(_err_handler, e)
void always_fails(pERR, int other_arg) {
THROW(42);
}
void does_some_stuff(pERR) {
normal_call(aERR);
HANDLE_ERRORS
TRY {
always_fails(aERR, 23);
} CATCH {
/* err is 42 */
}
END_HANDLE;
}
int main(int argc, char *argv[]) {
HANDLE_ERRORS
TRY {
does_some_stuff(aERR);
return 0;
} CATCH {
return err;
}
DONE_ERRORS;
}
--
Phew. I'm done. (Crazy examples untested. Some details might be off.)
And now for something completely different...
Another approach is to use a struct to contain your error information, e.g:
struct ErrorInfo
{
int errorCode;
char *errorMessage;
#if DEBUG
char *functionName;
int lineNumber;
#endif
}
The best way to use this is to return your method's results as the return code (e.g. "FALSE for failed", or "a file pointer or NULL if it fails", or "size of the buffer or 0 if it fails", etc) and pass in an ErrorInfo as a parameter that the called function will fill in if something fails.
This gives rich error reporting: if the method fails, you can fill in more than a simple error code (e.g. error message, code line and file of the failure, or whatever). The nice thing about it being a struct is that if you think of something, anything, useful later, you can just add it - for example, in my struct above I've allowed for a debug build to include the location of the error (file/line), but you could add a dump of the whole call stack in there at any time without having to change any of the client code.
You can use a global function to fill in an ErrorInfo so the error return can be managed cleanly, and you can update the struct to provide more info easily:
if (error)
{
Error(pErrorInfo, 123, "It failed");
return(FALSE);
}
...and you can have variants of this function that return FALSE, 0, or NULL, to allow most error returns to be phrased as a single line:
if (error)
return(ErrorNull(pErrorInfo, 123, "It failed"));
This gives you a lot of the advantages of an Exception class in other languages (although the caller still needs to handle the errors - callers have to check for error codes and may have to return early, but they can do nothing or next-to-nothing and allow the error to propagate back up a chain of calling methods until one of them wishes to handle it, much like an exception.
In addition, you can go further, to create a chain of error reports (like "InnerException"s):
struct ErrorInfo
{
int errorCode;
char *errorMessage;
...
ErrorInfo *pInnerError; // Pointer to previous error that may have led to this one
}
Then, if you "catch" an error from a function that you call, you can create a new, higher-level error description, and return a chain of these errors. e.g. "Mouse speed will revert to the default value" (because) "Preference block 'MousePrefs' could not be located" (because) "XML reader failed" (because) "File not found".
i.e.
FILE *OpenFile(char *filename, ErrorInfo *pErrorInfo)
{
FILE *fp = fopen(filename, "rb");
if (fp == NULL)
return(ChainedErrorNull(pErrorInfo, "Couldn't open file"));
return(fp);
}
XmlElement *ReadPreferenceXml(ErrorInfo *pErrorInfo)
{
if (OpenFile("prefs.xml", pErrorInfo) == NULL)
return(ChainedErrorNull(pErrorInfo, "Couldn't read pref"));
...
}
char *ReadPreference(char *prefName, ErrorInfo *pErrorInfo)
{
XmlElement *pXml = ReadPreferenceXml(pErrorInfo);
if (pXml == NULL)
return(ChainedErrorNull(pErrorInfo, "Couldn't read pref"));
...
}
You should check out what DirectX has done with the HRESULT - it's basically this. There's a reason that the exception came into being. Alternatively, if you run on Win32, they have SEH which runs in C programs.
You can get really silly and do continuations:
void step_1(int a, int b, int c, void (*step_2)(int), void (*err)(void *) ) {
if (!c) {
err("c was 0");
} else {
int r = a + b/c;
step_2(r);
}
}
This probably isn't actually what you want to do, but it is how many functional programming languages are used, and even more often how they model their code for optimization.
Something I've recently seen is this idom:
int err;
do
{
err = func1 (...);
if (!err) break;
err = func2 (...);
if (!err) break;
err = func3 (...);
if (!err) break;
/* add more calls here */
} while (0);
if (err)
{
/* handle the error here */
return E_ERROR; /* or something else */
}
else
{
return E_SUCCESS;
}
Pro arguments:
It avoids the goto (abuses the while(0) / break combination for that). Why would you want to do this? It keeps the cyclomatic complexity down and will still pass most static code analyzer checks (MISRA anyone?). For projects that get tested against cyclomatic complexity this is a god sent because it keeps all the initialization stuff together.
Contra arguments:
The meaning of the do/while loop construct is not obvious because a loop-construct is used as a cheap goto replacement, and this can only be seen at the loop tail. I'm sure for the first time this construct will cause lots of "WTF"-moments.
At least a comment is necessary to explain why the code is written the way it is required.
Here's a quite informative article & test file by IBM Unix article series:
Errors: errno in UNIX programs
Working with the standard error mechanism
https://www.ibm.com/developerworks/aix/library/au-errnovariable/
Another good example of how to implement exit codes is the source code of curl (man 1 curl).
Provided you are working with a specific context, I think the following pattern is very nice. The basic idea is that operations on an error-set state are no-ops, so error checking can be postponed to when it is convenient!
A concrete example: A deserialization context. Decoding of any element can fail, but the function may continue without error checking because all the decode_* functions are no-ops when the serialization record is in an error state. It's a matter of convenience or opportunity or optimization to insert decode_has_error. In the example below, there is no error check, the caller will take care of that.
void list_decode(struct serialization_record *rec,
struct list *list,
void *(*child_decode)(struct serialization_record *)) {
uint32_t length;
decode_begin(rec, TAG);
decode_uint32(rec, &length);
for (uint32_t i = 0; i < length; i++) {
list_append(list, child_decode(rec));
}
decode_end(rec, TAG);
}