Weird memory leak in ProcRenderCreateCursor()
radu.rendec at gmail.com
Mon May 20 15:24:02 UTC 2019
I'm running X.Org 1.20.4 from Fedora 29 and I'm seeing some weird memory
leak (sort of) that seems to occur in ProcRenderCreateCursor().
I ran the X server under valgrind and the allocated memory is not really
lost (it's still reachable) and in fact it's properly cleaned up on a
normal shutdown - I had to instrument the code to do an immediate
_exit(0) on SIGUSR2 to catch this. However, the allocated memory doesn't
seem to be reclaimed/reused while the server is still running.
The scenario to reproduce the problem is somewhat weird too: running
VirtualBox with a Linux Mint live iso as guest and installing to a USB
stick inside the guest (the USB stick is exported to the guest through
I am aware that the problem is likely in VirtualBox and *not* in X.Org,
but it's really odd that the allocated memory is only released during
the X.Org server shutdown and *not* when VirtualBox is closed.
While the Linux Mint installer is running in the VirtualBox guest, X.Org
server memory footprint grows at about 1 MByte/s, so it can easily fill
up a large amount of memory in relatively short time.
A valgrind log snippet is included below. I also have a full valgrind
execution tree (that can be viewed in e.g. kcachegrind) and shows the
exact location of the leak. I can provide it if needed.
I would very much appreciate any information/suggestion to further debug
this problem. Thank you!
==5640== HEAP SUMMARY:
==5640== in use at exit: 1,092,164,136 bytes in 378,790 blocks
==5640== total heap usage: 5,681,727 allocs, 5,302,937 frees, 4,067,121,449 bytes allocated
==5640== xtree leak report: /any/xtleak.kcg.5640
==5640== LEAK SUMMARY:
==5640== definitely lost: 599,929 bytes in 37,330 blocks
==5640== indirectly lost: 348 bytes in 8 blocks
==5640== possibly lost: 3,140,032 bytes in 10,764 blocks
==5640== still reachable: 1,088,423,827 bytes in 330,688 blocks
==5640== of which reachable via heuristic:
==5640== newarray : 39,720 bytes in 145 blocks
==5640== suppressed: 0 bytes in 0 blocks
More information about the xorg