[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: Memory leakage.

Leif
Again as you are clearly a much more accomplished programmer than I, I hope I am not telling you to "suck eggs" :) but
One of the principal ideas in C++ is to encapsulate the object and present a consistent interface 

If XCreateFontCursor is a class (it may not be)
the class code will be often in a header file say "xCreateFontCursor.h" and a code file say "xCreateFontCursor.cpp" (However they might be buried in another file somewhere)
The header will declare the various parts of the object (attributes) which may consist of functions and data objects such as variables. Some of the attributes may be other objects 
It will assign "access rights" eg public, private to the various attributes.
The code for each function will be in the .cpp file
At least One function will be a constructor named

XCreateFontCursor ::XCreateFontCursor ()

This creates the object and initializes it.
This function can be "overloaded" ie have several identical looking functions with different numbers of parameters creating different objects, depending on the context - it is this aspect that makes C++ so hard to follow at times I reckon 

There is (usually) a destructor

XCreateFontCursor ::~XCreateFontCursor ()  // (note the ~)
The constructor is automatically called when an object of the class is invoked. The destructor code should make sure the object is properly destroyed when no longer required. It looks as though different functions are called here to create and destroy the object so it is probably not in C++! As another poster says, it is probably not a mission critical issue at this point if the leak is small 

Richard





Leif Asbrink wrote:
I do not understand what "the class code for this" means. Not at all being a programmer I become confused. 

When reading about C++ (which I find alien and impractical)
I get the impression that Class is simply a data structure,
a list of variables that could contain data or pointers
to data, pointers or routines.

It seems to me that XCreateFontCursor does not only allocate
memory to cross_cursor which I can free with XFreeCursor,
it must also allocate something else - maybe routines needed
by the pointers to routines in the list of pointers constituting
the data of cross_cursor. My problem is that I can not find out
whether I should call some XCloseCursorThings (or whatever) after
having freed the last cursor. Finding XFreeCursor was not
a trivial thing. One would expect the man page about XCreateFontCursor to give a hint - but it does not:-(
I was hoping someone could tell me proper name of XCloseCursorThings if something like that exists - or 
tell me that the code below is perfectly correct and complete
and that I should disregard the valgrind output.

73

Leif / SM5BSZ






No doubt there are more accomplished programmers who could advise..

Richard


Leif Asbrink wrote:


Hello Richard,
Lost memory is allocated when an object in C++ is created , but not released when the object is destroyed. This is usually performed by the destructor for the class if the class has been written properly. 
???????????????
I have seen similar text before, but it does not tell me anything
at all. I have for example this problem. Only four simple statements:

xdis = XOpenDisplay(":0");
cross_cursor = XCreateFontCursor(xdis, XC_diamond_cross);
XFreeCursor(xdis, cross_cursor);
XCloseDisplay(xdis);
return 0;

If I comment out the second and the third statement all is ok,
but with both of them in place I get this report from valgrind:
==9031== LEAK SUMMARY:
==9031==    definitely lost: 8 bytes in 1 blocks.
==9031==    indirectly lost: 104 bytes in 4 blocks.
This results in increasing useless RAM utilization and eventually disk swapping, slowing everything down.
How can I detect whether it happened? 



(hope I am not telling you things you already know.. :)  )

You told things I kind of heard about but that I do not
understand how to deal with. Did I make a mistake in the
example above or is X11 not quite ok yet? Do you know?
Using pthreads is much worse..............

73

Leif


#############################################################
This message is sent to you because you are subscribed to
the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>




#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>



#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>



#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>
LINRADDARNIL