GNU bug report logs - #21509
25.0.50; X11 error: BadPixmap when creating first emacsclient frame; and memory leak

Previous Next

Full log

View this message in rfc822 format

From: Dima Kogan <dima <at> secretsauce.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21509 <at> debbugs.gnu.org
Subject: bug#21509: 25.0.50; X11 error: BadPixmap when creating first emacsclient frame; and memory leak
Date: Mon, 04 Sep 2017 23:21:32 -0700

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

> Dima, just in case you're still around

Hi. I'm around, just don't have time to work on emacs as much as I would
like.


> I now installed in master a "fix" for this, see also the discussion of
> Bug#27816.
>
> Can you try it and also check whether it has any implications on the
> memory leak problem?

Thank you very much for tracking this down!

I'm at the current HEAD (979797b9eca0ab009cc75a29765f998ec2aa1b45). This
is after your fix was applied.

I gathered data with 4 different sets of code:

- Lucid widgets. At HEAD, but with the fix (commit
  d577d1609c6c9d11b6af30a33e02bb21ffa821fd) pulled out. This should
  trigger this bug. Confirmed.

- Lucid widgets. At HEAD, with fix pulled out (same as above), but with
  the scroll bar turned off. This bug should not be triggered. Confirmed
  also.

- Lucid widgets. At HEAD, without any changes. The fix is in place. The
  bug should not be triggered. Again, confirmed. The fix works.

- GTK widgets. At HEAD, without any changes.

For each of these cases, I started a daemon with

  dima <at> scrawny:~/emacs/src$ ./emacs -Q --daemon=tst

Then I looped the client, repeatedly spawning and killing new frames
(same as what I was doing when looking for leaks before)

  dima <at> scrawny:~/emacs/lib-src$ while true; do timeout 1 ./emacsclient
  -a '' -c -s tst; sleep 1; done;

At the same time, I'd collect memory usage data:

  dima <at> scrawny:~$ while true; do ps -h -p PID -O rss; sleep 1; done | tee /tmp/logfile

I'm attaching the gathered data for all the cases, and a plot made with
this command:

  $ cat \
    <(< /tmp/before.log awk '{print NR,"nofix_yesscroll",$2}') \
    <(< /tmp/before.no.scroll.log  awk '{print NR,"nofix_noscroll",$2}') \
    <(< /tmp/after.yes.scroll.log awk '{print NR,"yesfix_yesscroll",$2}') \
    <(< /tmp/after.yes.scroll.gtk.log awk '{print NR,"yesfix_yesscroll_gtk",$2}') \
    | feedgnuplot --lines --dataid --domain --autolegend --xlabel 'frame index (2 seconds per frame)' --ylabel 'Memory consumed (kB)'

So in the case of lucid widgets, you not only fixed the bug, but also
massively plugged the memory leaks that were associated with new emacs
frames. Awesome!

The fix doesn't affect GTK, so that plot is just for reference. It's
clearly still leaking, and its baseline memory usage is higher. I was
thinking that GTK does a larger number of small allocations that are
soon freed, and thus suffers from more fragmentation issues. To test
that, I invoked malloc_trim(0) just after t=450 in the gtk run. This
asks malloc to return the the kernel all the unused memory it's holding.
And we see a 5MB drop. So the GTK leaks aren't as bad as they look.

So yeah. Good fix and thanks.

[before.log (application/octet-stream, attachment)]

[before.no.scroll.log (application/octet-stream, attachment)]

[after.yes.scroll.log (application/octet-stream, attachment)]

[after.yes.scroll.gtk.log (application/octet-stream, attachment)]

[emacs21509.pdf (application/pdf, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.