Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!novia!news-out.readnews.com!news-xxxfer.readnews.com!panix!panix.com!mrbrklyn
From: Ruben Safir <mrbrklyn@panix.com>
Newsgroups: comp.lang.c++
Subject: Re: Interpeting valgrind
Date: Fri, 27 May 2011 18:08:51 +0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Lines: 138
Message-ID: <iropbj$fp6$2@reader1.panix.com>
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> <ireoit$iph$1@hoshi.visyn.net> <irf5kn$at1$1@reader1.panix.com> <a6138f2d-ab8f-412a-ae9e-cf2a82cd553d@dn9g2000vbb.googlegroups.com>
NNTP-Posting-Host: panix5.panix.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: reader1.panix.com 1306519731 16166 166.84.1.5 (27 May 2011 18:08:51 GMT)
X-Complaints-To: abuse@panix.com
NNTP-Posting-Date: Fri, 27 May 2011 18:08:51 +0000 (UTC)
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (NetBSD/5.1 (i386))
Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:5718

Michael Doubez <michael.doubez@free.fr> wrote:
> On 24 mai, 04:37, Ruben Safir <ru...@mrbrklyn.com> wrote:
>> On Tue, 24 May 2011 00:54:17 +0200, Kai-Uwe Bux wrote:
>> > Ruben Safir wrote:
>>
>> > [...]
>> >> But look at this
>> >> =3D=3D26349=3D=3D 121,600 (1,600 direct, 120,000 indirect) bytes in=
 100 blocks
>> >> are definitely lost in loss record 17 of 17 =3D=3D26349=3D=3D =A0 =A0=
at 0x4027400:
>> >> operator new(unsigned int) (in
>> >> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) =3D=3D26349=3D=3D=
 =A0 =A0by
>> >> 0x8048E49: creating_int_list() (test_del2.cpp:105) =3D=3D26349=3D=3D=
 =A0 =A0by
>> >> 0x8048A89: main (test_del2.cpp:55) =3D=3D26349=3D=3D
>>
>> >> Ok those lines are as follows - the call function designed to alloc=
ate
>> >> a list of integers and return them (in this case to main
>> >> =A0 =A0 =A0 std::cout << "CREATING LIST for ARRAY
>> >> =A0 =A0 =A0 -------------------------------\n"; a[i] =3D creating_i=
nt_list();
>>
>> >> chainlist::List<int> * creating_int_list(){
>> >> =A0 =A0// chainlist::List<int> =A0set =3D new chainlist::List<int>;
>> >> =A0 =A0chainlist::List<int> * set =3D new chainlist::List<int>; int=
 ran;
>> >> =A0 =A0for(int i =3D 0; i < 100; ++i){
>> >> =A0 =A0 =A0 ran=3Drand();
>> >> =A0 =A0 =A0 set->insert(ran % 100);
>> >> =A0 =A0}
>> >> =A0 =A0set->display();
>> >> =A0 =A0return set;
>> >> }
>>
>> >> If I chose to delete the returned List pointed to by set, it have t=
o be
>> >> done OUT of that function otherwise the function has no point
>>
>> >> So upon complaint i did just that
>>
>> >> =A0 =A0for( i=3D0; i < 100; ++i){
>> >> =A0 =A0 =A0 delete a[i];
>> >> =A0 =A0}
>> >> =A0 =A0return EXIT_SUCCESS;
>>
>> >> That had NO IMPACT on the report.
>> > [...]
>>
>> > Then, it looks as though the destructor of chainlist::List<int> is n=
ot
>> > releasing the resources properly. I looked upthread for that destruc=
tor.
>> > It relies upon a method remove_front() which you posted as:
>>
>> > =A0 =A0template<class T>
>> > =A0 =A0 =A0 void List<T>::remove_front(){
>> > //// =A0 =A0 std::cout << "Removing the Front " << front() << " End =
of List
>> > is "<< endd() << std::endl;
>>
>> > =A0 =A0 =A0 =A0 =A0if(front() =3D=3D 0){
>> > // =A0 =A0 =A0 =A0 =A0std::cout << "Front =A0is NULL " << front() <<=
 std::endl;
>> > =A0 =A0 =A0 =A0 =A0 =A0 return;
>> > =A0 =A0 =A0 =A0 =A0}
>> > =A0 =A0 =A0 =A0 =A0if(front() =3D=3D endd()){
>> > //
>> > // =A0 =A0 =A0 =A0 =A0std::cout << "Front =A0is End " << front() << =
std::endl;
>> > =A0 =A0 =A0 =A0 =A0 =A0 Node<T> * tmp =3D front();
>> > =A0 =A0 =A0 =A0 =A0 =A0 delete tmp;
>> > =A0 =A0 =A0 =A0 =A0 =A0 front(0);
>> > =A0 =A0 =A0 =A0 =A0 =A0 endd(0);
>> > =A0 =A0 =A0 =A0 =A0 =A0 cursor() =3D 0;
>> > =A0 =A0 =A0 =A0 =A0 =A0 sizedown();
>> > =A0 =A0 =A0 =A0 =A0 =A0 return;
>> > =A0 =A0 =A0 =A0 =A0}
>>
>> > The code looks incomplete, so I cannot comment on the correctness. B=
ut
>> > that is, where I would search.
>>
>>
>> I've followed that code very closely and did a shake out of it a month
>> ago when I had a double delete. =A0It definitely walks through the ent=
ire
>> list and does the deletions, and the nodes have their own destructors.
>>
>> The pointers themselves can't be deleted and are automatic variable
>=20
> Well, there are many problem with your code. One is between main() and
> creating_int_list() and the other is that you didn't define a copy
> operator (and copy constructor) for your list.
>=20


I don't want a copy constructor in the list and there is no need for
one.  I don't want a 100meg list being copied around.  I want it to
remain in global space on the heap, to be only accessed by references
and pointers (although I'm aware that elide optimization would probably
prevent deep copies anyway).

> int main ( int argc, char *argv[] )
> {
>    chainlist::Node<std::string> * string_node;
>    chainlist::List<int> myintlist;
>    // ...
>    myintlist =3D creating_int_list();
>    // ...
> }
>=20
> chainlist::List<int>& creating_int_list(){
>        chainlist::List<int> * set =3D new chainlist::List<int>;
>        srand(12345);
>        int ran;
>        for(int i =3D 0; i < 5000; ++i){
>                ran=3Drand();
>                set->insert(ran % 101);
>        }
>        return *set;
> }
>=20
> I assume you used new here in order to avoid the double delete you
> mentioned.


No - I did that in order to be able to move the pointer of the list out
of the function and keep the list available in the gobal scope.  You
can't pass out the local List<> unless it is on the heap.
=20

>=20
> --
> Michael
>=20