I am coding in C and receiving a malloc error with the error message:
malloc: *** error for object 0x7fe9d44026d8: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
The objective of my code is to store a generated maze into a 2D array from a string that stores the maze using the read() function. I am not having trouble reading the maze into the string but when I pass the string, number of rows, and number of columns as parameters to a function
What exactly does this malloc error mean? And how can I determine which part of my code is creating this error?
Your implementation of malloc() does additional checks not required by the C language standard. In this case, it seems to detect that some data in a memory block was modified after it was marked as free (by a call to free()). That's a bug in your program.
To find the culprit, use a memory debugging tool. For *nix systems, there is valgrind. On windows, you can use drmemory. These tools replace the memory management functions of your standard library and will notify you instantly about errors such as writing to some memory that was already free()d.
Related
You are most likely seeing this question because your question has been closed as a duplicate of this. For a moderately complete list of related questions, please see A long list of possible duplicates — C memory allocation and overrunning bounds on Meta Stack Overflow.
Example Question
From free char*: invalid next size (fast) asked by noobie on 2014-04-11.
I am freeing a char* after a concatenation process, but I receive this error:
free(): invalid next size (fast): 0x0000000001b86170
This is my code:
void concat(stringList *list) {
char *res = (char*)malloc(sizeof(char*));
strcpy(res, list->head->string);
list->tmp = list->head->next;
while (list->tmp != NULL) {
strcat(res, ",");
strcat(res, list->tmp->string);
list->tmp = list->tmp->next;
}
printf("%s\n", res);
free(res);
}
Generic Question
When running my program, I see an error message like this:
*** glibc detected *** ./a.out: free(): corrupted unsorted chunks: 0x12345678 ***
The detailed information can contain any of the following after the *** glibc detected *** and the program name, and the message is followed by a hexadecimal address (shown as 0x12345678) and another ***:
free(): corrupted unsorted chunks: 0x12345678
free(): invalid next size (fast): 0x12345678
free(): invalid next size (normal): 0x12345678
free(): invalid pointer: 0x12345678
free(): invalid size: 0x12345678
malloc(): corrupted unsorted chunks: 0x12345678
malloc(): corrupted unsorted chunks 2: 0x12345678
malloc(): memory corruption: 0x12345678
malloc(): memory corruption (fast): 0x12345678
malloc(): smallbin double linked list corrupted: 0x12345678
munmap_chunk(): invalid pointer: 0x12345678
realloc(): invalid next size (fast): 0x12345678
realloc(): invalid old size (fast): 0x12345678
realloc(): invalid pointer: 0x12345678
corrupted double-linked list: 0x12345678
This happens while calling the frobnicate() function; what is wrong with that function?
Answer for Example Question
unwind gave the accepted answer to the example question:
Your code is wrong.
You are allocating space for a single pointer (malloc(sizeof(char*))), but no characters. You are overwriting your allocated space with all the strings, causing undefined behavior (in this particular case, corrupting malloc()'s book-keeping data).
You don't need to allocate space for the pointer (res); it's a local variable. You must allocate space for all the characters you wish to store at the address held by the pointer.
Since you're going to be traversing a list to find strings to concatenate, you can't know the total size upfront. You're going to have to do two passes over the list: one to sum the strlen() of each string, then allocate that plus space for the separator and terminator, then another pass when you actually do the concatenation.
Generic Answer
What you are seeing is the result of a corruption in the internal structures of the glibc allocator. When you are allocating or freeing dynamic memory, the allocator has to manage the memory it reserved from the OS and, depending on the action requested by you, find a new chunk to hand out, sort a freed chunk into the list of those that it can hand out later again, or give the memory back to the operating system. These error messages show that the data structures it uses to manage this functionality are corrupted.
These errors all mean that some of your code has modified memory that it was not given to use, invoking undefined behaviour. This is most likely the result of overwriting some memory quite a bit earlier in your program, and it is totally possible that the error does not lie in the frobnicate() function.
Yes, this means that the error can be anywhere in your program or 3rd party libraries you use.
This is probably not a good question for Stack Overflow. Unless you have a good simple reproduction of your problem, this community may be unable to help you very much. The cause of the error can be anywhere in your code (and is very often not in the function where the error is spotted), and it may be in code that we cannot see. Stack Overflow is not a collaborative debugging site. Even when someone can find the flaw in your code, it is unlikely that your specific question will ever help any future visitor.
Common causes
Use after free. You have freed/deleted some memory and writing into it afterwards, overwriting the structures glibc needs for bookkeeping.
Off-by-N error. You are writing N bytes after an allocated chunk into unallocated memory that glibc uses internally for its bookkeeping.
Uninitialized pointers. You are not initializing a pointer. By coincidence it points to some memory reserved by glibc but not allocated by your program and you write to it.
Allocating the wrong amount of space. This can be because you wrote long *data = malloc(number * 4) instead of long *data = malloc(number * sizeof(long)); or (better) long *data = malloc(number * sizeof(*data));. There are many other ways to get the size calculation wrong. Another common one is to forget to account for the null terminator character at the end of a string: char *copy = malloc(strlen(str)); instead of char *copy = malloc(strlen(str)+1);.
What you need to do now is to roll up your sleeves and debug that problem
There is no simple answer what to look for, or what to fix. No single syntactical construct that you were using wrong. The cause of this bug can come in literally thousands of varieties.
Tools
valgrind A tool created mostly for the purpose of finding exactly this kinds of errors. If it can't find anything make sure you are using the latest version, and you are also trying out the included exp-sgcheck tool. If you are running multithreaded code, the cause might also be related to a race condition so you might want to try the included race condition checkers drd and helgrind for more insight. At the point of writing this, valgrind supports the following platforms:
X86/Linux,
AMD64/Linux,
ARM/Linux,
PPC32/Linux,
PPC64/Linux,
S390X/Linux,
MIPS32/Linux,
MIPS64/Linux,
ARM/Android (2.3.x and later),
X86/Android (4.0 and later),
X86/Darwin and
AMD64/Darwin (Mac OS X 10.7, with limited support for 10.8).
purify A similar tool to valgrind, but commercial and aimed at a different set of platforms.
AddressSanitizer A similar tool, but integrated into the compiler toolchain (gcc and clang).
efence A drop in allocator replacement that will try to crash your program earlier, so that you can find out with a normal debugger where the write to invalid memory happened.
dmalloc a library with a similar purpose as efence.
Needing more assistance
If you can't solve your problem using one these tools, you should try to create an MCVE (How to create a Minimal, Complete, and Verifiable Example?) or, equivalently, an SSCCE (Short, Self Contained, Correct (Compilable), Example).
Remember to work on a copy of your code because creating an MCVE requires you to ruthlessly remove code that does not help reproduce the problem. Using a VCS (version control system) to assist is a good idea; you can record intermediate stages in reducing the problem to a minimum. It might be a new throw-away repository just for reducing your problem to a manageable size.
With a good modular design to your code, it should be relatively easy to create the MCVE. Maybe you also already have a unit test that is better suited to be fed into one of the above tools. You also might just want to create one that can later serve as a regression test for this bug.
I seem to be getting a sigabrt crash every once in a while (not every time).
malloc: *** error for object 0x7ff8884644c0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug.
Now, I know that means I'm probably attempting to access, or change an object after calling free() on it, but I was wondering how to find out what object it's referring to, using the memory address listed above. Thanks!
This is what I see before it crashes (It crashes on NSLog):
One option might be to use a debug malloc replacement such as dmalloc that can help you track source file & line number of malloc/free calls.
First, a little background so you won't think I'm attempting to do something insane:
I'm trying to debug a crash in a C library that was written by someone else. The crash looks like this:
TheProgram(44365,0x7fff75996310) malloc: *** error for object 0x7fb8d4b9d440: pointer being freed was not allocated
The crash occurs on a system where I can't run valgrind, alas. The first thing I did was wrap debug-print-macros around all of the library's calls to malloc(), calloc(), realloc(), and free() so that I see printf() output whenever memory is allocated/reallocated/freed by the library. From that debug output, it appears that the pointer that makes free() crashing was indeed allocated previously in the program, and that it wasn't freed before the problem free() call:
JJ_CHECK_MALLOC at [fastgr.c : 265] malloc() returned 0x7fb8d4b9d440
[...]
JJ_CHECK_FREE at [dotinit.c : 204] about to call free(0x7fb8d4b9d440)
TheProgram(44365,0x7fff75996310) malloc: *** error for object 0x7fb8d4b9d440: pointer being freed was not allocated
So presumably what must be happening is that somewhere after the call to malloc() and before the call to free(), the heap must be getting corrupted in such a way that free() no longer thinks that that pointer is valid.
What I need to do, then, is track down the routine that is causing the heap corruption. One way I could do this is to query the validity of the pointer at various places along the execution path, and narrow down where its status changes from "valid heap pointer" to "the heap manager doesn't know what this pointer is". But the only way I know of to find out whether the heap manager thinks the pointer is free-able is to call free(), which I obviously can't do while the program still wants to use the pointer. Is there some way to call the check-if-pointer-is-in-heap function that free() uses, without actually freeing the data?
In general: No.
There are "debugging heaps" which surround allocated blocks with additional "fence" information to help detect bad-pointer errors. These will fairly reliably complain if you try to free something that wasn't allocated through them, since the fences will be missing. (They'll also complain if you've overwritten the end of the buffer and damaged the fence, of course.) In environments where code changed frequently, I've sometimes run with these heaps permanently enabled despite the performance costs... but one would hope that they could normally be turned off before the code ships to customers.
First of all, I'm not sure this is a specific platform error. I'm using openssl library to generate big prime number and private/public keys. It ran fine when prime number is relatively small (128 bits), but I can't compile and got an error when the prime number was getting bigger (256, 512 bits).
DH * params = DH_new();
params = DH_generate_parameters(512, 5, NULL, NULL);
DH_generate_key(params); // can't get through this point when prime bits getting bigger
above code produced an error:
malloc: *** error for object 0x7ffba8403c88: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
I'm using openssl 1.0.1 on MAC OX 10.8.2. I'd appreciate for any advices.
UPDATE: Another way to produce this kind's error is creating a thread before above code. Either way, it always gave me error at sub-routine DH_generate_key.
Error messages related to heap corruption such as this message from malloc() indicate that you have memory management bugs, such as using memory after freeing it, or overrunning the allocated memory. It is normal for such malloc() error messages to occur at different locations than where the actual programming error happened. Run your application in Valgrind to get some useful information on what's going wrong.
Unrelated to the error, but you have a memory leak in these two lines of your code above:
DH * params = DH_new();
params = DH_generate_parameters(512, 5, NULL, NULL);
The pointer to the allocated DH structure is overwritten in the second line with a new DH structure returned by DH_generate_parameters(). The buffer allocated by DH_new() is lost. This is not the cause of the error message though.
Earlier I encountered a problem with dynamic memory in C (visual studio) .
I had a more or less working program that threw a run-time error when freeing one of the buffers. It was a clear memory corruption, the program wrote over the end of the buffer.
My problem is, that it was very time consuming to track down. The error was thrown way down after the corruption, and i had to manually debug the entire run to find when is the buffer end overwritten.
Is there any tool\ way to assist in tracking down this issue? if the program would have crashed immediately i would have found the problem a lot faster...
an example of the issue:
int *pNum = malloc(10 * sizeof(int));
// ||
// \/
for(int i = 0; i < 13; i++)
{
pNum[i] = 3;
}
// error....
free(pNum);
I use "data breakpoints" for that. In your case, when the program crashes, it might first complain like this:
Heap block at 00397848 modified at 0039789C past requested size of 4c
Then, start your program again, and set a data breakpoint at address 0039789C. When the code writes to that address, the execution will stop. It often happens that i find the bug immediately at this point.
If your program allocates and deallocates memory repeatedly, and it happens to be at this exact address, just disable deallocations:
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_DELAY_FREE_MEM_DF);
I use pageheap. This is a tool from Microsoft that changes how the allocator works. With pageheap on, when you call malloc, the allocation is rounded up to the nearest page(a block of memory), and an additional page of virtual memory that is set to no-read/no-write is placed after it. The dynamic memory you allocate is aligned so that the end of your buffer is just before the end of the page before the virtual page. This way, if you go over the edge of your buffer, often by a single byte, the debugger can catch it easily.
Is there any tool\ way to assist in tracking down this issue?
Yes, that's precisely the type of error which static code analysers try to locate. e.g. splint/PC-Lint
Here's a list of such tools:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Edit: In trying out splint on your code snippet I get the following warning:
main.c:9:2: Possible out-of-bounds store: pnum[i]
Presumably this warning would have assisted you.
Our CheckPointer tool can help find memory management errors. It works with GCC 3/4 and Microsoft dialects of C.
Many dynamic checkers only catch accesses outside of an object, and then only if the object is heap allocated. CheckPointer will find memory access errors inside a heap-allocated object; it is illegal to access off the end of a field in a struct regardless of the field type; most dynamic checkers cannot detect such errors. It will also find accesses off the edge of locals.