On Tue, Feb 09, 2016 at 02:43:32AM +0000, Stuart Henderson wrote:
> I just noticed xstatbar using "quite a lot" more memory than I was
> expecting. Does anyone fancy trying to track down the leak? It doesn't
> look like any flags are needed to trigger the leak, but using "-s 0"
> to avoid sleeping between updates makes it very easy to spot.
> [...]
I've attached a patch to fix that. The problem is that XCopyArea
generates either a GraphicsExpose or a NoExpose event after it's done.
Since xstatbar doesn't have the traditional X event loop, the events
just accumulate in the queue. I'll talk to upstream to integrate the
patch there, since I assume this doesn't only affect Xenocara.
--
Gregor
Index: Makefile
===================================================================
RCS file: /mnt/media/cvs/ports/sysutils/xstatbar/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile 3 Jul 2015 08:42:19 -0000 1.16
+++ Makefile 9 Feb 2016 10:20:42 -0000
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS= ${APM_ARCHS}
COMMENT= simple system monitor bar
DISTNAME= xstatbar-0.5
-REVISION= 7
+REVISION= 8
CATEGORIES= sysutils x11
Index: patches/patch-xstatbar_c
===================================================================
RCS file: patches/patch-xstatbar_c
diff -N patches/patch-xstatbar_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-xstatbar_c 9 Feb 2016 10:20:24 -0000
@@ -0,0 +1,18 @@
+--- xstatbar.c.orig Tue Feb 9 11:18:02 2016
++++ xstatbar.c Tue Feb 9 11:19:05 2016
+@@ -297,6 +297,7 @@
+ void
+ draw()
+ {
++ XEvent dummy;
+ static int spacing = 10;
+ int x, y;
+ int cpu;
+@@ -323,6 +324,7 @@
+ /* copy the buffer to the window and flush */
+ XCopyArea(XINFO.disp, XINFO.buf, XINFO.win, XINFO.gc,
+ 0, 0, XINFO.width, XINFO.height, 0, 0);
++ XNextEvent(XINFO.disp, &dummy);
+ XFlush(XINFO.disp);
+ }
+
