XORG memory leak?

ROOT
1

When I delete / recreate a TRootEmbeddedCanvas,
i note an increase of the memory used by xorg.

Look at this simple macro xorgproblem.C (1.06 KB)

Open top, look at xorg memory,
start the macro, click the button on the top many times,
and you will see the memory leak.

Tested with root 5.26d and many Linux distros, 32/64 bit.

Help me!
YAWN

2

Hi,

What are trying to achieve? creating/deleting windows is not a good idea, since the window allocated by X11 itself will not be freed until Root terminates.
Before starting to investigate a way to delete everything in your code, including the resources allocated by X11, it would be good to understand what you are trying to do, there is probably a better way to do it…

Cheers, Bertrand.

3

Hi,

Here is a possible solution. Just let me know if it is sufficient for you.

Cheers, Bertrand.
xorgsolution.C (1.37 KB)

4

Thanks for the help.

Your solution is interesting, and works in the example.
But i’m not able to adapt to my real code.

So, now i have a more complex application
xorgproblemapp.tar.gz (1.34 KB)

if you are interested in the problem… :smiley:

Thanks
YAWN

5

Hi,

One general (C++) comment: You must always initialize your pointers to 0, especially if you test their validity like: if (MyTableFrame) { ...
You can do it in the constructor of your class, for example:

MainFrame::MainFrame(const TGWindow *p): TGMainFrame(p), 
      MyCompositeFrame(0), MyTableFrame(0) {

Then, you could also replace this code:

if (MyTableFrame) { MyCompositeFrame->RemoveFrame(MyTableFrame); delete MyTableFrame; }
by MyCompositeFrame->Cleanup();
This code works for me on Linux(slc4) and Windows with svn trunk (didn’t try with other versions).
And about the memory, I don’t see real issues, the memory increase a bit when you create the frames, but then it stabilizes (i.e. creating and deleting frames doesn’t continuously increase the memory)

Cheers, Bertrand.

6

Thank you for the answer.
But no, i’m sure there is a memory leak.
I have also tested ROOT 5.27/04, and nothing changed:
memory usage of xorg increases continuosly.
(opensuse 11.3 and SL5.4, 64 bit)

Can anyone confirm the memory leak?

I think that the TCanvas created by TRootEmbeddedCanvas has to be closed in the destructor of the component.

Bye :smiley:
YAWN

7

Hi,

I’m a bit lost… You said:

[quote=“yawn”]Your solution is interesting, and works in the example.
But i’m not able to adapt to my real code.[/quote]But I have the same behavior with your code than with the example…

Anyway, can you test the following modification on your system?
Just add:

      if (fCanvas->GetCanvasID() >=0 ) {
         gVirtualX->SelectWindow(fCanvas->GetCanvasID());
         gVirtualX->CloseWindow();
      }

In the TRootEmbeddedCanvas destructor (in $ROOTSYS/gui/gui/src/TRootEmbeddedCanvas.cxx), as show below:

[code]//______________________________________________________________________________
TRootEmbeddedCanvas::~TRootEmbeddedCanvas()
{
// Delete embedded ROOT canvas.

if (!MustCleanup()) {
if (fCanvas->GetCanvasID() >=0 ) {
gVirtualX->SelectWindow(fCanvas->GetCanvasID());
gVirtualX->CloseWindow();
}
delete fCanvas;
delete fCanvasContainer;
}
delete [] fDNDTypeList;
}

[/code]
And let me know if it changes anything, please. And if you cannot make the change and/or build Root from source, then I’ll make more tests and I’ll let you know.

Cheers, Bertrand.

8

I changed the destructor of TRootEmbeddedCanvas, but my problem remains.
Ok, I need to investigate the problem a little more.

If I’ll have news, I’ll tell you :wink:

Cheers
YAWN

9

I was TOTALLY WRONG!

TRootEmbeddedCanvas is not the problem.
I have an XORG memory leak with a simple TGTextButton!

So, this is the updated app for testing
xorgproblemapp.tar.gz (1.2 KB)

If you don’t have the problem, I’ll post a VIDEO :wink:

Cheers
YAWN

10

Bertrand will be back only on October 25, so you must be patient.

Rene

11

Ok :wink: