🚀 go-pugleaf

I have been looking more closely, and it seems that XCheckMaskEvent()
allocates 104 bytes when a new event needs to be read from the
X-Server connection file descriptor.

It seems that from time to time the Queue of X events gets in
a screwy state, in which each call to XCheckMaskEvent(display, -1, &ev)
malloc's 104 bytes while returning False (I give the mask -1 to
get any event).  So it creates a memory leak...

I have not spent time debugging Xlib.

:-( :-(

Has anyone ever had this problem with Linux or Solaris ?

It it very easy to see it: let an interactive X
program run a looong time, and see the memory that it uses
gets larger and larger (slowly), or use debug_malloc, and see
thousands of lines like:


2649: *** alloc: at 'ra=0x400339e7' for 104 bytes, got '0x8315680|s1'
2650: *** alloc: at 'ra=0x400339e7' for 104 bytes, got '0x8315700|s1'
2651: *** alloc: at 'ra=0x400339e7' for 104 bytes, got '0x8315780|s1'
2652: *** alloc: at 'ra=0x400339e7' for 104 bytes, got '0x8315800|s1'
2653: *** alloc: at 'ra=0x400339e7' for 104 bytes, got '0x8315880|s1'
2654: *** alloc: at 'ra=0x400339e7' for 104 bytes, got '0x8315900|s1'


Regards, -- Tristan Savatier (mailto:tristan@mpegtv.com)
           
MpegTV website:   http://www.mpegtv.com
MPEG.ORG website: http://www.mpeg.org