Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!news2.arglkargh.de!news.visyn.net!visyn.net!not-for-mail
From: Kai-Uwe Bux <jkherciueh@gmx.net>
Newsgroups: comp.lang.c++
Subject: Re: Interpeting valgrind
Followup-To: comp.lang.c++
Date: Tue, 24 May 2011 00:54:17 +0200
Organization: University of Bielefeld
Lines: 80
Message-ID: <ireoit$iph$1@hoshi.visyn.net>
References: <irc4ok$dno$3@reader1.panix.com> <cone.1306107376.32708.16159.500@monster.email-scan.com> <70a85274-88f9-4a18-b45c-50f05e91773c@l26g2000yqm.googlegroups.com> <cone.1306113809.229005.17178.500@monster.email-scan.com> <irek9g$dno$4@reader1.panix.com>
Reply-To: jkherciueh@gmx.net
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Trace: hoshi.visyn.net CvK1yX2u47UcTNxYQhA/D+IL9mCCxtMFJ4nhTCoC1Ew=
X-Complaints-To: abuse@open-news-network.org
NNTP-Posting-Date: Mon, 23 May 2011 22:54:21 +0000 (UTC)
X-User-ID: o0d9GI78h5JgOk2Cl20Ahga7Qy3WXbUt+LIJ7wP9aejAey4oGWjBByU3Pil72u2y
User-Agent: KNode/4.4.11
Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:5377

Ruben Safir wrote:

[...] 
> 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.
[...]

Then, it looks as though the destructor of chainlist::List<int> is not 
releasing the resources properly. I looked upthread for that destructor. It 
relies upon a method remove_front() which you posted as:

   template<class T>
      void List<T>::remove_front(){
////     std::cout << "Removing the Front " << front() << " End of List is 
"<< endd() << std::endl;

         if(front() == 0){
//          std::cout << "Front  is NULL " << front() << std::endl;
            return;
         }
         if(front() == endd()){
//
//          std::cout << "Front  is End " << front() << std::endl;
            Node<T> * tmp = front();
            delete tmp;
            front(0);
            endd(0);
            cursor() = 0;
            sizedown();
            return;
         }

The code looks incomplete, so I cannot comment on the correctness. But that 
is, where I would search.


Best,

Kai-Uwe Bux