Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #5371

Re: Interpeting valgrind

Show all headers | View raw

On Sun, 22 May 2011 20:23:29 -0500, Sam wrote:

> mrbrklyn writes:
> 
>> On May 22, 7:36 pm, Sam <s...@email-scan.com> wrote:
>> > Ruben Safir writes:
>> > > I'm looking at valg5rind output.  Very interesting but I'm
>> > > wondering about its output
>> >
>> > > I see for example
>> >
>> > > ==2109==
>> > > ==2109== HEAP SUMMARY:
>> > > ==2109==     in use at exit: 249,696 bytes in 32,929 blocks
>> > > ==2109==   total heap usage: 39,794 allocs, 6,865 frees, 329,680
>> > > bytes allocated
>> > > ==2109==
>> > > ==2109== 4 bytes in 1 blocks are still reachable in loss record 1
>> > > of 17
>> >
>> > That means that there's a pointer to this block somewhere.
>> >
>> > > Anything not being destroyed is in global scope and left destroyed
>> > > internationally...or so i thought
>> >
>> > Well, somewhere it's not.
>> >
>> >
>> >
>> > > When the program ends, main stops and a whole cascade of deletes
>> > > happen.
>>  
>> > > I've seen that happen in this code
>> > > and even had double deletes at one point.
>> >
>> > > Am I not seeing something?
>> >
>> > If these blocks would get freed in the destructor, this must mean
>> > that the
>>  
>> > destructor never gets called. So you have an instance of this
>> > template
>> class
>> > somewhere.
>> >
>> > How does your code terminate? If your main() is calling exit(),
>> > exit()
>> never
>> > returns, hence main() never returns, hence anything that's
>> > instantiated in
>>  
>> > main() never gets destroyed.
>> >
>> >  application_pgp-signature_part
>> > < 1KViewDownload
>>
>> Really?  an exit prevents the closing clean up?  The code is
> 
> Correct. exit() generally terminates the process without unwinding the
> stack. valgrind wakes up, and complains about stuff that's still on the
> heap.
> 
> If you're instantiating non-static objects in main(), they go out of
> scope and destroyed only when main() returns (or upon exiting the nested
> block they were instantiated in, if they were instantiated in a nested
> block).
> 
> exit() never returns, main() never exits.


I'm not exiting.  I'm return from main .

But look at this
==26349== 121,600 (1,600 direct, 120,000 indirect) bytes in 100 blocks are definitely lost in loss record 17 of 17
==26349==    at 0x4027400: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26349==    by 0x8048E49: creating_int_list() (test_del2.cpp:105)
==26349==    by 0x8048A89: main (test_del2.cpp:55)
==26349== 



Ok those lines are as follows - the call function designed to allocate a list of integers and return them (in this case to 
main
      std::cout << "CREATING LIST for ARRAY -------------------------------\n";
      a[i] = creating_int_list();


chainlist::List<int> * creating_int_list(){
   // chainlist::List<int>  set = new chainlist::List<int>;
   chainlist::List<int> * set = new chainlist::List<int>;
   int ran;
   for(int i = 0; i < 100; ++i){
      ran=rand();
      set->insert(ran % 100);
   }
   set->display();
   return set;
}


If I chose to delete the returned List pointed to by set, it have to be done OUT of that function
otherwise the function has no point

So upon complaint i did just that


   for( i=0; i < 100; ++i){
      delete a[i];
   }
   return EXIT_SUCCESS;


That had NO IMPACT on the report.

 
==26592== 121,600 (1,600 direct, 120,000 indirect) bytes in 100 blocks are definitely lost in loss record 17 of 17
==26592==    at 0x4027400: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26592==    by 0x8048E49: creating_int_list() (test_del2.cpp:105)
==26592==    by 0x8048A89: main (test_del2.cpp:55)
==26592== 

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Interpeting valgrind Ruben Safir <ruben@mrbrklyn.com> - 2011-05-22 23:03 +0000
  Re: Interpeting valgrind Sam <sam@email-scan.com> - 2011-05-22 18:36 -0500
    Re: Interpeting valgrind mrbrklyn <ceo.brooklyn@gmail.com> - 2011-05-22 17:23 -0700
      Re: Interpeting valgrind Sam <sam@email-scan.com> - 2011-05-22 20:23 -0500
        Re: Interpeting valgrind Ruben Safir <ruben@mrbrklyn.com> - 2011-05-23 21:41 +0000
          Re: Interpeting valgrind Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-05-24 00:54 +0200
            Re: Interpeting valgrind Ruben Safir <ruben@mrbrklyn.com> - 2011-05-24 02:37 +0000
              Re: Interpeting valgrind Michael Doubez <michael.doubez@free.fr> - 2011-05-24 01:36 -0700
                Re: Interpeting valgrind Ruben Safir <mrbrklyn@panix.com> - 2011-05-27 18:08 +0000
                Re: Interpeting valgrind Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-27 22:43 +0000
                Re: Interpeting valgrind Ruben Safir <ruben@mrbrklyn.com> - 2011-05-27 23:01 +0000
                Re: Interpeting valgrind Michael Doubez <michael.doubez@free.fr> - 2011-05-29 12:41 -0700
            Re: Interpeting valgrind Ruben Safir <ruben@mrbrklyn.com> - 2011-05-24 02:48 +0000

csiph-web