Re: [Valgrind-users] phantom "new" at call leads to "definitely lost"

[Alan M. <al...@ju...>]

On 5/30/13 9:43 AM, David Chapman wrote:
> On 5/30/2013 9:15 AM, Alan Mazer wrote:
>> I've been using valgrind for many years and am finally stumped. After
>> not having used it recently, I'm now getting "definitely lost" memory
>> and the location of the "operator new" usage is a function call.
>>
>> For example...
>>
>> ==35995== 2,089 bytes in 1 blocks are definitely lost in loss record 9
>> of 10
>> ==35995==    at 0x10008FC16: malloc (vg_replace_malloc.c:274)
>> ==35995==    by 0x1000A126C: operator new(unsigned long) (in
>> /usr/local/lib/libstdc++.6.dylib)
>> ==35995==    by 0x10001984C: main (main.cpp:405)
>>
>> where main.cpp:405 is...
>>
>>       read_conf(conffile, ".conf;.test;.prot", preface, 
>> trigger_statement,
>>               skip_preprocessor, m4dirs, &text);
>>
>> Everything being passed is a pointer.
>>
>> If I don't call the routine, the error does go away.
>>
>> This type of error is occurring in a variety of places, always
>> "definitely lost" memory at a function call.
>>
>> Anyone have any idea what I'm missing?  I've tried multiple compilers
>> and a bazillion different options (on compiler and valgrind). I'm 
>> stumped.
>>
>> -- Alan
>>
>
> What is the signature of the function being called?  You say that 
> pointers are being passed in, but what does the function expect? For 
> example, is the compiler automatically creating an object for the 
> string constant using a default constructor?  (I realize the loss 
> record is longer than the string constant, but I don't know what the 
> function expects.)

Sure.  Good point.

extern int read_conf(const char *filename, const char *extensions,
     const char *preface, const char *postscript, u_char skip_preprocessor,
     SL_List<char *> *m4dirs, char **conf_text_p);


>
> Also, is the function in a .so file that has been stripped so that 
> Valgrind cannot follow it, stack trace?

No, there are no .so files here.  Just a bunch of object files linked 
together, all compiled with -g and -Wall, linked with -lm. I've tried 
with g++ 4.5.1 and 4.7.0.  They both give the same result.


>
> And of course, what version of Valgrind are you using?

3.8.1.

-- Alan