Free() invalid pointer - freeing array of pointers fails?

Up vote 1 down vote favorite share g+ share fb share tw.

I have been debugging a piece of legacy code, running on an XScale (arm v5te) System with linux, that crashes reproducible. I have debugged using gdb and set MALLOC_CHECK_ to 1. It's a lot of code, so just some snippets: We have this structure: typedef struct { ...clipped.. char **data_column_list; /** data column count */ int data_column_cnt; ...clipped } csv_t; We initialize the columns in a function, putting them in a variable "columns" /* Allocating memory for pointer to every register id */ columns = (char **) malloc(column_cnt * sizeof(char *)); column_cnt = 0; /* loop over all sensors */ for(i=0; idata_cnt; j++) { /* Storing all the pointers to id */ columnscolumn_cnt++ = cfg.

Sen_listi->data_listj->id; } } In another function, what happens is this: /* free the previous list */ csv_free(lc_csv); lc_csv->data_column_list = columns; lc_csv->data_column_cnt = column_cnt; csv_free being: void csv_free(csv_t *csv) { if(csv->data_column_cnt > 0) free(csv->data_column_list); csv->data_column_cnt = 0; } Now, there is another function, building the whole "cfg"/config structure, that contains these ids. Code frome above: cfg. Sen_listi->data_listj->id; where cfg is a struct, sen_list is an array of pointers to structs, data_list is an array of pointers to other structs, that contain a string "id".

Whe the program gets a signal SIGUSR1, the config is being updated. All of these data_list and sen_list structs are being freed, then new ones are generated. Then with the first function, new collumns of ids are generated and put into the csv structure, but the old list is being freed before.

Thats where it crashes. In csv_free. *** glibc detected *** /root/elv: free(): invalid pointer: 0x0001ae88 *** I thought it should be like this.

You have an array of pointers. When you free the pointers, you have to free the pointer, pointing to a set of pointers (the array). Or put in code terms, the above situation should be analog to: char **ar = malloc(n * sizeof(char *)); char *xn = malloc(10 * sizeof(char)); // Do for 0 to n strings ... arn = xn; // Do for 0 to n strings ...do stuff... free(xn); // Do for 0 to n strings free(ar); When the structs, containing the id strings, are freed, I still have my pointer arrays with (invalid) pointers, not null pointers: (gdb) p csv $40 = {sysid = 222, ip = '\0' , module = "elv_v2", '\0' , format_type = 1, msg_id = 0, data_column_list = 0x1ae88, data_column_cnt = 10, pub_int = 30, line_cnt = 0, pub_seq = -1, format = 0x18260} (gdb) p csv.

Data_column_list0 $41 = 0x1b378 "0" But I get the above error message (or SIGABRT without the MALLOC_CHECK_). I don't understand this at all. I have to free this array of pointers, or it will become a memory leak.

There is no other call of free before that, that I could find. I don't know why csv. Data_column_list is considered an invalid pointer.

Valgrind is unfortunately not availiable on arm v5te :( Have been debugging this for hours and hours and would be happy for any help. Thank you very much, Cheers, Ben UPDATE: I'm wondering if it could be connected to some "scope" issue. There is almost identical code in another application, which works.

The function which crashes, "csv_free" is used by both programs (statically linked). The only difference is, that the struct containing the pointer to be freed is declared and defined normally in the working program and declared as external and defined in another file than main. C Calling "free" manually in main.

C works, while calling "csv_free" crashes. Riddle me this... c memory-leaks malloc free link|improve this question edited Mar 20 at 15:41 asked Mar 16 at 15:22Ben413.

– Oli Charlesworth Mar 16 at 15:43 you should check csv is NULL or not in csv_free, and after freeing csv assign it with NULL. This will protect you from doing csv->member when csv is NULL or some garbage. – phoxis Mar 16 at 15:57 You said you're freeing pointers after SIGUSR1 is received.

Is that inside the signal handler? SIGUSR1 can be delivered at any time, so it may be unsafe to malloc or free inside the signal handler. If the signal is delivered when the program is inside another call to malloc/free, you could corrupt the heap.

– Jay Conrod Mar 16 at 16:37 Thank you guys for reading and commenting! @Als - as I said, Valgrind is not availiable for this platform. I was thinking about running it on my x86-64 machine, but I would need to recreate the environment to make the software work, e.g. , making virtual serial ports and supplying infos to them.

But that is quite a lot of effort. – Ben 6-641 at 11:40.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.