Sponsored Content
Top Forums Programming ./match_pattern.out: malloc(): memory corruption: 0x0000000013a11600 *** Post 302553849 by JohnGraham on Friday 9th of September 2011 02:56:10 AM
Old 09-09-2011
Quote:
Originally Posted by shoaibjameel123
I reckon its the problem with malloc(), free() pair.
Memory corruption is normally due to you straying outside the bounds of an array - not with malloc()/free() statements matching up. You've probably overwritten some of the space next to a malloc()'d portion of memory that glibc expects to be able to use for keeping track of the memory region - go through with a debugger and have a look for bounds errors.

As an aside, here's the sort of thing you can expect if you did have a problem with malloc()/free() pairs:

Code:
[john@john-laptop tmp.u6Q7IbZntd]$ cat prog.c
#include <stdlib.h>

int main(void)
{
    void *p = malloc(1);
    free(p);
    free(p);
    return 0;
}
[john@john-laptop tmp.u6Q7IbZntd]$ gcc prog.c -o prog
[john@john-laptop tmp.u6Q7IbZntd]$ ./prog
*** glibc detected *** ./prog: double free or corruption (fasttop): 0x09ba3008 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6c501)[0x58b501]
/lib/libc.so.6(+0x6dd70)[0x58cd70]
/lib/libc.so.6(cfree+0x6d)[0x58fe5d]
./prog[0x8048425]
/lib/libc.so.6(__libc_start_main+0xe7)[0x535ce7]
./prog[0x8048361]
======= Memory map: ========
0051f000-00676000 r-xp 00000000 08:04 2793795    /lib/libc-2.12.1.so
00676000-00678000 r--p 00157000 08:04 2793795    /lib/libc-2.12.1.so
00678000-00679000 rw-p 00159000 08:04 2793795    /lib/libc-2.12.1.so
00679000-0067c000 rw-p 00000000 00:00 0 
0091c000-0091d000 r-xp 00000000 00:00 0          [vdso]
00ab9000-00ad3000 r-xp 00000000 08:04 2793551    /lib/libgcc_s.so.1
00ad3000-00ad4000 r--p 00019000 08:04 2793551    /lib/libgcc_s.so.1
00ad4000-00ad5000 rw-p 0001a000 08:04 2793551    /lib/libgcc_s.so.1
00dd4000-00df0000 r-xp 00000000 08:04 2793792    /lib/ld-2.12.1.so
00df0000-00df1000 r--p 0001b000 08:04 2793792    /lib/ld-2.12.1.so
00df1000-00df2000 rw-p 0001c000 08:04 2793792    /lib/ld-2.12.1.so
08048000-08049000 r-xp 00000000 08:04 1220779    /tmp/tmp.u6Q7IbZntd/prog
08049000-0804a000 r--p 00000000 08:04 1220779    /tmp/tmp.u6Q7IbZntd/prog
0804a000-0804b000 rw-p 00001000 08:04 1220779    /tmp/tmp.u6Q7IbZntd/prog
09ba3000-09bc4000 rw-p 00000000 00:00 0          [heap]
b7500000-b7521000 rw-p 00000000 00:00 0 
b7521000-b7600000 ---p 00000000 00:00 0 
b76fc000-b76fd000 rw-p 00000000 00:00 0 
b7714000-b7716000 rw-p 00000000 00:00 0 
bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]
Aborted

 

10 More Discussions You Might Find Interesting

1. Programming

malloc gives the same memory to two different nodes. How to deal with it?

When allocating memory for two different nodes, the resulting memory are the same. Clearly, this will lead to a mistake. This happened in a function. And the process must be in a function. (gdb) p tree->list $43 = (node *) 0x8be4180 (gdb) p tree->list $44 = (node *) 0x8be4180 At the... (2 Replies)
Discussion started by: cdbug
2 Replies

2. UNIX for Dummies Questions & Answers

'memory corruption' error when using Awk

Hello, everyone. I got the following error when I am using awk to analysis some text file: *** glibc detected *** awk: malloc(): memory corruption: 0x080c67f8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6 /lib/tls/i686/cmov/libc.so.6... (5 Replies)
Discussion started by: kooyee
5 Replies

3. Programming

Why memory allocated through malloc should be freed ?

Actually for a process to run it needs text, stack , heap and data segments. All these find a place in the physical memory. Out of these 4 only heap does exist after the termination of the process that created it. I want to know the exact reason why this happens. Also why the other process need to... (20 Replies)
Discussion started by: karthiktceit
20 Replies

4. Programming

Why does this occur? *** glibc detected *** malloc(): memory corruption: 0x10013ff8 ***

there seems not to be error in this segment. In some computers, it can work well. But in others, it will give a failure. why it ocurrs and how to deal with it? in a function: if( *ver == NULL ) { *ver = (vertex *) malloc(sizeof(vertex)); //this line ... (17 Replies)
Discussion started by: cdbug
17 Replies

5. Programming

readdir and dynamic array memory corruption

Hi everyone I am developing an utility. At some part of it I read directory entries to a dynamic array: struct list It stores pointers to items: list.entries, which are structures: struct entry If a number of files in a directory is greater then number of elements an array was initially... (11 Replies)
Discussion started by: torbium
11 Replies

6. Programming

*** glibc detected *** ./a.out: malloc(): memory corruption (fast):

*** glibc detected *** ./a.out: malloc(): memory corruption (fast): Posted A minute ago M trying to make multiway tree and dont know what happend when this part of code get executed: 01void ins(NODE *ptr) 02{ 03 //working 04 if(ptr!=NULL) 05 { 06 SNODE *var=NULL; 07 var=(SNODE... (3 Replies)
Discussion started by: exgenome
3 Replies

7. Programming

*** glibc detected *** : malloc(): memory corruption (fast)

Hi Friends, while executing the below code, am getting *** glibc detected *** ./ok: malloc(): memory corruption (fast) error, please suggest how to solve this issue. #include <stdio.h> #include <string.h> #include <sqlca.h> #include <alloca.h> /* Define constants for VARCHAR... (2 Replies)
Discussion started by: mpjobsrch
2 Replies

8. Programming

*** glibc detected *** ./a.out malloc() memory corruption

I am facing a problem of memory corruption. The loop runs for the first time but does not go through the second time. What could be the problem? for(int z=0;z<2;z++) { fp=fopen("poly.dat","r"); /*do something which reads this file into a 2D array*/ fclose(fp); ... (10 Replies)
Discussion started by: dare
10 Replies

9. Solaris

Solaris 10 Shared Memory Corruption with X11

I am having a problem with shared memory corruption. I have two 86 servers running Solaris 10 (150400-06). One of the servers is accessed by a Sun Ray thin client Version 11.1.3.0.2.6. I login into server one from the thin client. I then ssh -X to server two. When a process that contains a... (2 Replies)
Discussion started by: salerno
2 Replies

10. Programming

Memory corruption in dynamic array of strings

I put together a C function to add strings to a dynamic array of strings (mostly for educational purpose to explain pointers to my kid). It works, but sometimes one or two strings in the array becomes corrupted. Running example on 64 bit Ubuntu, gcc ver. 4.8.4 Hope my code is self-explanatory: ... (2 Replies)
Discussion started by: migurus
2 Replies
MALLOPT(3)						     Linux Programmer's Manual							MALLOPT(3)

NAME
mallopt - set memory allocation parameters SYNOPSIS
#include <malloc.h> int mallopt(int param, int value); DESCRIPTION
The mallopt() function adjusts parameters that control the behavior of the memory-allocation functions (see malloc(3)). The param argument specifies the parameter to be modified, and value specifies the new value for that parameter. The following values can be specified for param: M_CHECK_ACTION Setting this parameter controls how glibc responds when various kinds of programming errors are detected (e.g., freeing the same pointer twice). The 3 least significant bits (2, 1, and 0) of the value assigned to this parameter determine the glibc behavior, as follows: Bit 0 If this bit is set, then print a one-line message on stderr that provides details about the error. The message starts with the string "*** glibc detected ***", followed by the program name, the name of the memory-allocation function in which the error was detected, a brief description of the error, and the memory address where the error was detected. Bit 1 If this bit is set, then, after printing any error message specified by bit 0, the program is terminated by calling abort(3). In glibc versions since 2.4, if bit 0 is also set, then, between printing the error message and aborting, the program also prints a stack trace in the manner of backtrace(3), and prints the process's memory mapping in the style of /proc/[pid]/maps (see proc(5)). Bit 2 (since glibc 2.4) This bit has an effect only if bit 0 is also set. If this bit is set, then the one-line message describing the error is sim- plified to contain just the name of the function where the error was detected and the brief description of the error. The remaining bits in value are ignored. Combining the above details, the following numeric values are meaningful for M_CHECK_ACTION: 0 Ignore error conditions; continue execution (with undefined results). 1 Print a detailed error message and continue execution. 2 Abort the program. 3 Print detailed error message, stack trace, and memory mappings, and abort the program. 5 Print a simple error message and continue execution. 7 Print simple error message, stack trace, and memory mappings, and abort the program. Since glibc 2.3.4, the default value for the M_CHECK_ACTION parameter is 3. In glibc version 2.3.3 and earlier, the default value is 1. Using a nonzero M_CHECK_ACTION value can be useful because otherwise a crash may happen much later, and the true cause of the prob- lem is then very hard to track down. M_MMAP_MAX This parameter specifies the maximum number of allocation requests that may be simultaneously serviced using mmap(2). This parame- ter exists because some systems have a limited number of internal tables for use by mmap(2), and using more than a few of them may degrade performance. The default value is 65,536, a value which has no special significance and which servers only as a safeguard. Setting this parame- ter to 0 disables the use of mmap(2) for servicing large allocation requests. M_MMAP_THRESHOLD For allocations greater than or equal to the limit specified (in bytes) by M_MMAP_THRESHOLD that can't be satisfied from the free list, the memory-allocation functions employ mmap(2) instead of increasing the program break using sbrk(2). Allocating memory using mmap(2) has the significant advantage that the allocated memory blocks can always be independently released back to the system. (By contrast, the heap can be trimmed only if memory is freed at the top end.) On the other hand, there are some disadvantages to the use of mmap(2): deallocated space is not placed on the free list for reuse by later allocations; memory may be wasted because mmap(2) allocations must be page-aligned; and the kernel must perform the expensive task of zeroing out memory allocated via mmap(2). Balancing these factors leads to a default setting of 128*1024 for the M_MMAP_THRESHOLD parameter. The lower limit for this parameter is 0. The upper limit is DEFAULT_MMAP_THRESHOLD_MAX: 512*1024 on 32-bit systems or 4*1024*1024*sizeof(long) on 64-bit systems. Note: Nowadays, glibc uses a dynamic mmap threshold by default. The initial value of the threshold is 128*1024, but when blocks larger than the current threshold and less than or equal to DEFAULT_MMAP_THRESHOLD_MAX are freed, the threshold is adjusted upwards to the size of the freed block. When dynamic mmap thresholding is in effect, the threshold for trimming the heap is also dynami- cally adjusted to be twice the dynamic mmap threshold. Dynamic adjustment of the mmap threshold is disabled if any of the M_TRIM_THRESHOLD, M_TOP_PAD, M_MMAP_THRESHOLD, or M_MMAP_MAX parameters is set. M_MXFAST (since glibc 2.3) Set the upper limit for memory allocation requests that are satisfied using "fastbins". (The measurement unit for this parameter is bytes.) Fastbins are storage areas that hold deallocated blocks of memory of the same size without merging adjacent free blocks. Subsequent reallocation of blocks of the same size can be handled very quickly by allocating from the fastbin, although memory frag- mentation and the overall memory footprint of the program can increase. The default value for this parameter is 64*sizeof(size_t)/4 (i.e., 64 on 32-bit architectures). The range for this parameter is 0 to 80*sizeof(size_t)/4. Setting M_MXFAST to 0 disables the use of fastbins. M_PERTURB (since glibc 2.4) If this parameter is set to a nonzero value, then bytes of allocated memory (other than allocations via calloc(3)) are initialized to the complement of the value in the least significant byte of value, and when allocated memory is released using free(3), the freed bytes are set to the least significant byte of value. This can be useful for detecting errors where programs incorrectly rely on allocated memory being initialized to zero, or reuse values in memory that has already been freed. M_TOP_PAD This parameter defines the amount of padding to employ when calling sbrk(2) to modify the program break. (The measurement unit for this parameter is bytes.) This parameter has an effect in the following circumstances: * When the program break is increased, then M_TOP_PAD bytes are added to the sbrk(2) request. * When the heap is trimmed as a consequence of calling free(3) (see the discussion of M_TRIM_THRESHOLD) this much free space is preserved at the top of the heap. In either case, the amount of padding is always rounded to a system page boundary. Modifying M_TOP_PAD is a trade-off between increasing the number of system calls (when the parameter is set low) and wasting unused memory at the top of the heap (when the parameter is set high). The default value for this parameter is 128*1024. M_TRIM_THRESHOLD When the amount of contiguous free memory at the top of the heap grows sufficiently large, free(3) employs sbrk(2) to release this memory back to the system. (This can be useful in programs that continue to execute for a long period after freeing a significant amount of memory.) The M_TRIM_THRESHOLD parameter specifies the minimum size (in bytes) that this block of memory must reach before sbrk(2) is used to trim the heap. The default value for this parameter is 128*1024. Setting M_TRIM_THRESHOLD to -1 disables trimming completely. Modifying M_TRIM_THRESHOLD is a trade-off between increasing the number of system calls (when the parameter is set low) and wasting unused memory at the top of the heap (when the parameter is set high). Environment Variables A number of environment variables can be defined to modify some of the same parameters as are controlled by mallopt(). Using these vari- ables has the advantage that the source code of the program need not be changed. To be effective, these variables must be defined before the first call to a memory-allocation function. (If the same parameters are adjusted via mallopt() then the mallopt() settings take prece- dence.) For security reasons, these variables are ignored in set-user-ID and set-group-ID programs. The environment variables are as follows (note the trailing underscore at the end of the name of each variable): MALLOC_CHECK_ This environment variable controls the same parameter as mallopt() M_CHECK_ACTION. If this variable is set to a nonzero value, then a special implementation of the memory-allocation functions is used. (This is accomplished using the malloc_hook(3) feature.) This implementation performs additional error checking, but is slower than the standard set of memory-allocation functions. (This imple- mentation does not detect all possible errors; memory leaks can still occur.) The value assigned to this environment variable should be a single digit, whose meaning is as described for M_CHECK_ACTION. Any characters beyond the initial digit are ignored. For security reasons, the effect of MALLOC_CHECK_ is disabled by default for set-user-ID and set-group-ID programs. However, if the file /etc/suid-debug exists (the content of the file is irrelevant), then MALLOC_CHECK_ also has an effect for set-user-ID and set- group-ID programs. MALLOC_MMAP_MAX_ Controls the same parameter as mallopt() M_MMAP_MAX. MALLOC_MMAP_THRESHOLD_ Controls the same parameter as mallopt() M_MMAP_THRESHOLD. MALLOC_PERTURB_ Controls the same parameter as mallopt() M_PERTURB. MALLOC_TRIM_THRESHOLD_ Controls the same parameter as mallopt() M_TRIM_THRESHOLD. MALLOC_TOP_PAD_ Controls the same parameter as mallopt() M_TOP_PAD. RETURN VALUE
On success, mallopt() returns 1. On error, it returns 0. ERRORS
On error, errno is not set. CONFORMING TO
This function is not specified by POSIX or the C standards. A similar function exists on many System V derivatives, but the range of val- ues for param varies across systems. The SVID defined options M_MXFAST, M_NLBLKS, M_GRAIN, and M_KEEP, but only the first of these is implemented in glibc. BUGS
Specifying an invalid value for param does not generate an error. A calculation error within the glibc implementation means that a call of the form: mallopt(M_MXFAST, n) does not result in fastbins being employed for all allocations of size up to n. To ensure desired results, n should be rounded up to the next multiple greater than or equal to (2k+1)*sizeof(size_t), where k is an integer. The MALLOC_MMAP_THRESHOLD_ and MALLOC_MMAP_MAX_ variables are not ignored in set-group-ID programs. If mallopt() is used to set M_PERTURB, then, as expected, the bytes of allocated memory are initialized to the complement of the byte in value, and when that memory is freed, the bytes of the region are initialized to the byte specified in value. However, there is an off-by- sizeof(size_t) error in the implementation: instead of initializing precisely the block of memory being freed by the call free(p), the block starting at p+sizeof(size_t) is initialized. EXAMPLE
The program below demonstrates the use of M_CHECK_ACTION. If the program is supplied with an (integer) command-line argument, then that argument is used to set the M_CHECK_ACTION parameter. The program then allocates a block of memory, and frees it twice (an error). The following shell session shows what happens when we run this program under glibc, with the default value for M_CHECK_ACTION: $ ./a.out main(): returned from first free() call *** glibc detected *** ./a.out: double free or corruption (top): 0x09d30008 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6c501)[0x523501] /lib/libc.so.6(+0x6dd70)[0x524d70] /lib/libc.so.6(cfree+0x6d)[0x527e5d] ./a.out[0x80485db] /lib/libc.so.6(__libc_start_main+0xe7)[0x4cdce7] ./a.out[0x8048471] ======= Memory map: ======== 001e4000-001fe000 r-xp 00000000 08:06 1083555 /lib/libgcc_s.so.1 001fe000-001ff000 r--p 00019000 08:06 1083555 /lib/libgcc_s.so.1 [some lines omitted] b7814000-b7817000 rw-p 00000000 00:00 0 bff53000-bff74000 rw-p 00000000 00:00 0 [stack] Aborted (core dumped) The following runs show the results when employing other values for M_CHECK_ACTION: $ ./a.out 1 # Diagnose error and continue main(): returned from first free() call *** glibc detected *** ./a.out: double free or corruption (top): 0x09cbe008 *** main(): returned from second free() call $ ./a.out 2 # Abort without error message main(): returned from first free() call Aborted (core dumped) $ ./a.out 0 # Ignore error and continue main(): returned from first free() call main(): returned from second free() call The next run shows how to set the same parameter using the MALLOC_CHECK_ environment variable: $ MALLOC_CHECK_=1 ./a.out main(): returned from first free() call *** glibc detected *** ./a.out: free(): invalid pointer: 0x092c2008 *** main(): returned from second free() call Program source #include <malloc.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { char *p; if (argc > 1) { if (mallopt(M_CHECK_ACTION, atoi(argv[1])) != 1) { fprintf(stderr, "mallopt() failed"); exit(EXIT_FAILURE); } } p = malloc(1000); if (p == NULL) { fprintf(stderr, "malloc() failed"); exit(EXIT_FAILURE); } free(p); printf("main(): returned from first free() call "); free(p); printf("main(): returned from second free() call "); exit(EXIT_SUCCESS); } SEE ALSO
mmap(2), sbrk(2), mallinfo(3), malloc(3), malloc_hook(3), malloc_info(3), malloc_stats(3), malloc_trim(3), mcheck(3), mtrace(3), posix_memalign(3) COLOPHON
This page is part of release 3.44 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2012-04-30 MALLOPT(3)
All times are GMT -4. The time now is 05:56 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy