void *
m_malloc(int size)
{
void *p;
if ( (p = malloc(size)) == NULL) {
assert(FALSE);
return NULL;
}
return p;
}

In debug mode program crashes in malloc function by signal (SIGABRT)
size = 3396

console output:
*** glibc detected *** /home/din/Projects/new-daProject/Debug/manager: malloc(): memory corruption: 0x0b16fcc0 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7d57256]
/lib/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb7d58655]
/home/din/Projects/new-daProject/Debug/manager[0x8064833]
/home/din/Projects/new-daProject/Debug/manager[0x805e65b]
/home/din/Projects/new-daProject/Debug/manager[0x805f4e5]
/home/din/Projects/new-daProject/Debug/manager[0x805fff9]
/home/din/Projects/new-daProject/Debug/manager[0x805622e]
/home/din/Projects/new-daProject/Debug/manager[0x8050c6b]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7cfc455]
/home/din/Projects/new-daProject/Debug/manager(__gxx_personality_v0+0x1f5)[0x8050241]
======= Memory map: ========
08048000-081b9000 r-xp 00000000 fe:02 1115467 /home/din/Projects/new-daProject/Debug/manager
081b9000-081bb000 rw-p 00171000 fe:02 1115467 /home/din/Projects/new-daProject/Debug/manager
081bb000-083af000 rw-p 081bb000 00:00 0
099f2000-0b18b000 rw-p 099f2000 00:00 0 [heap]
b7300000-b7321000 rw-p b7300000 00:00 0
b7321000-b7400000 ---p b7321000 00:00 0
b74ca000-b74cb000 ---p b74ca000 00:00 0
b74cb000-b7ccd000 rw-p b74cb000 00:00 0
b7ccd000-b7ce2000 r-xp 00000000 fe:00 227684 /lib/i686/cmov/libpthread-2.7.so
b7ce2000-b7ce4000 rw-p 00014000 fe:00 227684 /lib/i686/cmov/libpthread-2.7.so
b7ce4000-b7ce6000 rw-p b7ce4000 00:00 0
b7ce6000-b7e3b000 r-xp 00000000 fe:00 227691 /lib/i686/cmov/libc-2.7.so
b7e3b000-b7e3c000 r--p 00155000 fe:00 227691 /lib/i686/cmov/libc-2.7.so
b7e3c000-b7e3e000 rw-p 00156000 fe:00 227691 /lib/i686/cmov/libc-2.7.so
b7e3e000-b7e41000 rw-p b7e3e000 00:00 0
b7e41000-b7e4d000 r-xp 00000000 fe:00 217731 /lib/libgcc_s.so.1
b7e4d000-b7e4e000 rw-p 0000b000 fe:00 217731 /lib/libgcc_s.so.1
b7e4e000-b7e72000 r-xp 00000000 fe:00 227676 /lib/i686/cmov/libm-2.7.so
b7e72000-b7e74000 rw-p 00023000 fe:00 227676 /lib/i686/cmov/libm-2.7.so
b7e74000-b7e75000 rw-p b7e74000 00:00 0
b7e75000-b7f58000 r-xp 00000000 fe:00 234186 /usr/lib/libstdc++.so.6.0.10
b7f58000-b7f5b000 r--p 000e2000 fe:00 234186 /usr/lib/libstdc++.so.6.0.10
b7f5b000-b7f5d000 rw-p 000e5000 fe:00 234186 /usr/lib/libstdc++.so.6.0.10
b7f5d000-b7f63000 rw-p b7f5d000 00:00 0
b7f63000-b7f75000 r-xp 00000000 fe:00 49860 /usr/lib/libboost_filesystem.so.1.41.0
b7f75000-b7f76000 rw-p 00012000 fe:00 49860 /usr/lib/libboost_filesystem.so.1.41.0
b7f76000-b7f79000 r-xp 00000000 fe:00 49856 /usr/lib/libboost_system.so.1.41.0
b7f79000-b7f7a000 rw-p 00002000 fe:00 49856 /usr/lib/libboost_system.so.1.41.0
b7f7a000-b7f8c000 r-xp 00000000 fe:00 241676 /usr/lib/libboost_thread.so.1.41.0
b7f8c000-b7f8d000 rw-p 00012000 fe:00 241676 /usr/lib/libboost_thread.so.1.41.0
b7f8d000-b7f94000 r-xp 00000000 fe:00 227694 /lib/i686/cmov/librt-2.7.so
b7f94000-b7f96000 rw-p 00006000 fe:00 227694 /lib/i686/cmov/librt-2.7.so
b7f96000-b7f97000 rw-p b7f96000 00:00 0
b7fac000-b7fad000 rw-p b7fac000 00:00 0
b7fad000-b7fae000 r-xp b7fad000 00:00 0 [vdso]
b7fae000-b7fc8000 r-xp 00000000 fe:00 219778 /lib/ld-2.7.so
b7fc8000-b7fca000 rw-p 0001a000 fe:00 219778 /lib/ld-2.7.so
bfdce000-bfde3000 rw-p bffeb000 00:00 0 [stack]

The point in your program where the problem is detected and reported is not where the problem actually occurred (so the Backtrace you quoted would be useless even with the source code pointed to be that Backtrace).

I'm not sure exactly what the 0x0b16fcc0 points to. I think it is the address of a corrupted location. You can run the program in gdb and tell it to break on every write to that location. If it is the corrupted location, that would break when malloc uses that location, then break again when the bug in your code corrupts the location that should still belong to malloc.

Most likely your code malloc'ed some other object earlier and then used more than the full size of that other object. That corrupted data structures after that object that malloc needs in order to handle a later allocation.

Thanks - gdb helps - bug was outside

In this scenario, what is the benefit and/or use of the memory map? I am trying to find a bug with a similar output and want to understand as much as I can to try and find it.

Thanks much!
Rick

In this specific case, no benefit and/or use, but the OP didn't know that.

In cases like this, probably no benefit. But without knowing a lot more detail it isn't possible to determine which information will be needed to diagnose the bug.

Thanks but I think my question is even more basic than that.

When malloc detects these conditions, it does a back trace, dumps the memory map, and generates the core file. It's nice from a general standpoint to see the listing but it would seem it has a more purposeful reason for being dumped, one I'm not aware of... Like, maybe you can look at the the address and compare it to the map to see what process is using the space or ???

My specifics are a little more complex in that there are about 40 threads running at any one time. It takes about 8 to 12 hours for this to happen... It's not a memory leak as memory is not getting consumed... I'm at the point where I'm thinking of writing my own wrappers to encapsulate the memory and verify it's boundaries when it is freed... I am using MALLOC_CHECK_=2 and running with valgrind right now.

Thanks for the response.
Rick