search

minlexx / test_xlib_xdamage

me learning to use X11 XDamage extension
GNU General Public License v3.0
0 stars 0 forks source link

Memory leak? #1

Open nompelis opened 4 years ago

nompelis commented 4 years ago

Sorry to open up this issue 4 years after the repo has not been touched, but I ran into this problem on my system and thought I'd mention it here. I use Slackware 14.x (Linux kernel 3.x.x for this test).

While running this code, the damage trapped by the Xdamage extension object that has been created with "XDamageReportRawRectangles" leaves behind un-cleaned (non-freed) objects if the XDamageSubtract is called with None, None as the repair region arguments. I do not know why that is, and by reading the official Xdamage extension by Keith P. I cannot make sense of it. If the Subtract (to perform the repair) is not called, no memory objects will be left behind.

If you just want to trap Xdamage events but not deal with them, you can create the Xdamage object with the bounding boxes option.

To not leave behind unfreed memory you need to use the Xfixes extension to deal with those objects.

If you want to trap those damaged regions of the drawable and not leave memory behind and also not use Xfixes to deal with them, you can play tricks with XGetImage (or subimage). I am currently testing whether what I am suggesting here is a better way to deal with Xdamage that using Xfixes as it pertains to my purposes. I am trying to capture changes on a real X server display and send them across a network, just as the x11vnc code does. (Looking into that code confused the crap out of me, so I went on my own).

minlexx commented 4 years ago

Hi, so where is the leak? In application (somewhere in xlib/xcb)? Or in xserver itself? How can I see the leak?

What would be the correct way to deal with it?

nompelis commented 4 years ago

To spot the leak execute your code inside a terminal. It will immediately trap Xdamage events and will start to throw things on the screen, which will obviously become additional Xdamage events, and the process will never end. Keep that window going.

Now in a separate terminal start a top, filter programs as you please, and observe your code continuously bloating the memory that it occupies. Then, stop your Xdamage code, comment out the "Subtract" call to the Xdamage extension's API and execute again. Now you should be observing a constant memory footprint. This is what happened with my code, which was initially exactly like yours.

I do not know what the correct way to fix it is, but I will find out. I know that x11vnc (VNC for real X servers) does not leave leaks behind, and it uses the Xfixes extension to deal with the damage. I do not want to direct your to look at the x11vnc code, because it is very VERY convoluted. But I found an example that may do the trick. Look here: https://github.com/schuhumi/fbink-xdamage/blob/master/main.c Look starting at this line: https://github.com/schuhumi/fbink-xdamage/blob/6fd5e509ec36f901bb937ad78728781d2b16affb/main.c#L253 and until line 272. In that code --which I have not tried-- a function is supposed to do stuff with the region that was harvested from the Xdamage event.

I would like to know what you find, should you choose to go after this. I will be looking at potentially using the same procedure as the code I am referencing, but I have another way to do it that may better suit my needs.

nompelis commented 3 years ago

Any progress on this?

minlexx commented 3 years ago

What..? No.. X is dead in 2021 use wayland :)

On a more serious note this code was written many years ago as some sort of experiment to test working with low-level xlib api, and I don't even remember how it works, and I don't work with xlib anymore. It is possible that it contains errors, and if you think x11vnc code is correct, you can use it instead. I didn't do any more tests with this.

I probably worked on this stuff while I was porting KDE's vnc server program (krfb) old Qt4/x11 backend to new Qt5/xcb API and this code was taken from old x11 krfb plugin, as seen in comments in code (like the ones that use QX11Info::display()) but then I've never looked at it again :)

nompelis commented 3 years ago

Wait, what? Is it 2021 already? No way man! Wayland is for Ubuntuer's. ;-) I went from XF86 in 1993 to Xorg and I am sticking with it! I also hate KDE and GNOME (I use fvwm2 or homebrewed WMs).

On a serious note, I do not think that you have generated any bugs, but that the way we are supposed to use the Xdamage extension is problematic in that it allows for this memory leak to be created internally while it is not obvious that fragments remain behind. The documentation for Xdamage is also poor, neglects to mention that they key (but not the only) way to deal with this is to use Xfixes (another extension).

My way is to use Xdamage in a different mode, where I only get the damage rectangles but I am not expected to handle them with Xfixes; I query regions of the image with a different construct, which may be less efficient.

I have tried to understand what is going on with x11vnc but cannot. But it leaves no issues behind, so the proper way to do is is hidden in that software.

I will keep this issue open just in case any other poor soul runs into it and shows us the solution. For everyone reading, help!