Why is this free failing when calling execvp?

Question

First of all, I'm running in C on a Windows 32 bit system compiled with Visual Studio 2008. I'm running in debug mode. My code essentially is this:

execvp( *argv, argv );

Where argv has three entries and looks like this:

argv[0] = "pgserv";
argv[1] = "pgserv";
argv[2] = NULL;

Yes, I am aware that that calls the pgserv application with pgserv as an argument, but that works fine from the command line and is sort of an artifact of the framework this is a part of.

Anyway, when this line is hit, it triggers this assert in dbgheap.c/_free_dbg_nolock()

_ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));

Top of the call stack:

hub.exe!_free_dbg_nolock(void * pUserData=0x024c1408, int nBlockUse=1)  Line 1323 + 0x54 bytes  C++
hub.exe!_free_dbg(void * pUserData=0x024c1408, int nBlockUse=1)  Line 1258 + 0xd bytes  C++
hub.exe!free(void * pUserData=0x024c1408)  Line 49 + 0xb bytes  C++
hub.exe!_execve(const char * name=0x02523a10, const char * const * argv=0x02514e38, const char * const * envp=0x00000000)  Line 322 + 0x8 bytes C
hub.exe!_execvpe(const char * filename=0x02523a10, const char * const * argvector=0x02514e38, const char * const * envptr=0x00000000)  Line 87 + 0xc bytes  C
hub.exe!_execvp(const char * filename=0x02523a10, const char * const * argvector=0x02514e38)  Line 47 + 0xd bytes   C
hub.exe!execmd(char * cmd=0x02523a10)  Line 25 + 0xf bytes  C

I'm completely at a loss as to why I'd be getting this assert here as I believe I'm calling execvp() correctly and this code is called quite frequently with differing argv's successfully. Any ideas/help as to what my problem is? Thanks.

Answer 1

Is argv properly null terminated? From the docs, "The array of pointers must be terminated by a NULL pointer":

const char* args[] =  {"pgserv", "pgserv", NULL};

then call it with

execvp(args[0], args)

When you call it with only the first two parameters defined, ask yourself, "How can execvp determine the end of the list of strings?" The answer is that it looks for two NULLs in a row, which you're not providing.

Answer 2

A failure in free typically means one of two things: either you're trying to free a pointer that you didn't obtain from malloc (or that you've already freed), or the heap has become corrupted. Since the free is coming from the system library, odds are that your code has corrupted the heap earlier, and the memory allocation system has only just noticed.

Since you're already in a debugger, look what object was shortly before 0x024c1408. You probably overflowed a buffer there. (Of course, you may already have freed the offending object before calling execvp, in which case the bug could be hard to track down.)