Well given your inability to use malloc correctly for just making a copy of a string, I'd say you've screwed up on some other malloc call elsewhere in your "bigger program".
If you do this, anywhere, at any time, with any kind of pointer (this is just an example with strings)
char *p = malloc(10);
strcpy(p, "oops, this is too long to fit in 10 bytes");
Then you might observe one or more of the following
- absolutely nothing unusual, program works as expected
- program crashes on exit
- program crashes immediately
- program crashes on the next malloc
- program crashes on the next free
- program crashes on some random future malloc/free
- program crashes on some access of allocated memory
- program crashes on ....
Well, you get the idea.
Trashed memory pools are like minefields. The damage has been done, it's only a question of how long before you find out.
One thing is for sure, staring at the crash site is seldom productive. Chances are, the problem really occurred at some point in the past.
Finding the real problem is a challenge, but help is at hand if you're on Linux (Windows users have to hand over lots of $$$ to get something similar).
Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void foo ( void ) {
char *p = malloc(10);
strcpy(p, "oops, this is too long to fit in 10 bytes");
}
int main(void)
{
foo();
printf("OK so far...\n");
return 0;
}
$ gcc -g bar.c
$ ./a.out
OK so far...
$ valgrind ./a.out
==2377== Memcheck, a memory error detector
==2377== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2377== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==2377== Command: ./a.out
==2377==
==2377== Invalid write of size 1
==2377== at 0x4026975: memcpy (mc_replace_strmem.c:497)
==2377== by 0x8048484: foo (bar.c:7)
==2377== by 0x8048494: main (bar.c:11)
==2377== Address 0x4199032 is 0 bytes after a block of size 10 alloc'd
==2377== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==2377== by 0x8048465: foo (bar.c:6)
==2377== by 0x8048494: main (bar.c:11)
==2377==
==2377== Invalid write of size 1
==2377== at 0x402697E: memcpy (mc_replace_strmem.c:497)
==2377== by 0x8048484: foo (bar.c:7)
==2377== by 0x8048494: main (bar.c:11)
==2377== Address 0x4199033 is 1 bytes after a block of size 10 alloc'd
==2377== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==2377== by 0x8048465: foo (bar.c:6)
==2377== by 0x8048494: main (bar.c:11)
==2377==
==2377== Invalid write of size 1
==2377== at 0x4026964: memcpy (mc_replace_strmem.c:497)
==2377== by 0x8048484: foo (bar.c:7)
==2377== by 0x8048494: main (bar.c:11)
==2377== Address 0x4199034 is 2 bytes after a block of size 10 alloc'd
==2377== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==2377== by 0x8048465: foo (bar.c:6)
==2377== by 0x8048494: main (bar.c:11)
==2377==
==2377== Invalid write of size 1
==2377== at 0x402696C: memcpy (mc_replace_strmem.c:497)
==2377== by 0x8048484: foo (bar.c:7)
==2377== by 0x8048494: main (bar.c:11)
==2377== Address 0x4199035 is 3 bytes after a block of size 10 alloc'd
==2377== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==2377== by 0x8048465: foo (bar.c:6)
==2377== by 0x8048494: main (bar.c:11)
==2377==
==2377== Invalid write of size 1
==2377== at 0x40269B4: memcpy (mc_replace_strmem.c:497)
==2377== by 0x8048484: foo (bar.c:7)
==2377== by 0x8048494: main (bar.c:11)
==2377== Address 0x4199050 is not stack'd, malloc'd or (recently) free'd
==2377==
OK so far...
==2377==
==2377== HEAP SUMMARY:
==2377== in use at exit: 10 bytes in 1 blocks
==2377== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==2377==
==2377== LEAK SUMMARY:
==2377== definitely lost: 10 bytes in 1 blocks
==2377== indirectly lost: 0 bytes in 0 blocks
==2377== possibly lost: 0 bytes in 0 blocks
==2377== still reachable: 0 bytes in 0 blocks
==2377== suppressed: 0 bytes in 0 blocks
==2377== Rerun with --leak-check=full to see details of leaked memory
==2377==
==2377== For counts of detected and suppressed errors, rerun with: -v
==2377== ERROR SUMMARY: 32 errors from 5 contexts (suppressed: 13 from 8)
The red block is the call stack showing you where the illegal memory reference happened.
The blue block is the call stack to where that memory was allocated.
Follow each one, and decide whether to allocate more memory, or write less data.