Weird memory leak in ProcRenderCreateCursor()

[Radu Rendec]

Hi Everyone,

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
VirtualBox).

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!

Best regards,
Radu Rendec

8<-----------------------------------------------------------------

==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== 
==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