|
From: Eliot M. <mo...@cs...> - 2013-02-12 02:56:59
|
On 2/11/2013 6:04 PM, David Hourn (DTH Design) wrote: > Cheers guys, > > After reviewing the code the general issues I was having was memory management, and trying to access > memory that had been freed. Having only started coding in C two days ago it's probably a fair common > problem. > > This is the full code that I am using (I should've done this yesterday. Didn't think to pastebin) > http://pastebin.com/tewJSX3W > > Compiling and running that code through valgrind gives me no errors which is great, however there is > still 12 non-freed blocks at the end. 9 definitely lost - Am I right in saying these are getInput.in > (allocated line 25), getInputNoNewline.input (allocated line 39) and main.IntIn(initialised line > 51). And there are 3 still reachable blocks, which i'm guessing are the three blocks that make up > the players array (allocated line 53) ? Well, you make 9 input calls, each of which allocates a buffer, and you allocate the players array (it is one malloc object, even though it is 3 structs). You free the players array, but none of the strings it points to. The 3 IntIn assignments are blocks just dropped. In getInput, input and in point to the same place, so should not be a problem. This code will not necessarily work right if there is an I/O error or fgets reads NO chars at all. Likewise, getInputNoNewline may make an improper access: you should check len > 0 *before* accessing in[len - 1]. The still-reachable blocks mystify me a little. The only one I see is the last IntIn, since players is freed and the rest won't be reachable from any accessible variable. Of course there are block in library routines, such as an I/O buffer for stdout, etc. Regards -- Eliot Moss |