From: Dima Kogan <dima@secretsauce.net>
To: 21509@debbugs.gnu.org
Subject: bug#21509: 25.0.50; X11 error: BadPixmap when creating first emacsclient frame; and memory leak
Date: Thu, 17 Sep 2015 21:41:00 -0700 [thread overview]
Message-ID: <877fno9w6b.fsf@secretsauce.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]
Hi. I'm continuing the hunt for memory leaks:
http://lists.gnu.org/archive/html/emacs-devel/2015-09/msg00619.html
As noted in that post, even after fixing the winner-mode problem, memory
still leaks, albeit slowly. Chasing down that leak led me to this bug.
The issue is an X11 BadPixmap error thrown maybe 20% of the time when
the FIRST client frame is opened. I have only tested with the lucid
widgets. Steps:
1. emacs -Q --daemon
2. In bash: while true; do timeout 1 emacsclient -a '' -c; sleep 1; done;
So I spawn a new frame kill it after 1 second, then wait 1 more second
and repeat. Most of the time this looks like what you'd expect. About
20% of the time, however, the new X window pops up momentarily, and
instantly goes away. What's happening internally is apparently an X11
error that blows up the window. This isn't printed anywhere, but I use
perf to see it:
# perf probe -x /usr/bin/emacs --add 'x_connection_closed error_message:string'
...
# perf record -p `pidof emacs` -eprobe_emacs:x_connection_closed
... Ctrl-c when done
# perf script
emacs-tst 24692 [000] 443392.814048: probe_emacs:x_connection_closed: (4c0000) error_message_string="X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55"
This clearly shouldn't happen. I've been running my emacs as a daemon
for years, however and I've never seen this. It turns out that this
happens ONLY if we creates/destroy the only frame. If instead, we
1. create one frame by keeping an instance of the client open
2. Run the above bash snippet to repeatedly create/destroy the second
frame, then this X error does not happen, and everything works.
Another part of this is that when an X frame dies in this way, we leak
memory. The biggest offender is the font system. Normally, when a frame
is created, we open some fonts with xftfont_open(). Then when the frame
is destroyed x_delete_terminal() is called, which among other things
does
if (dpyinfo->display)
XtCloseDisplay();
which frees the fonts. If we get an X error, however, then
x_connection_closed() runs first. This sets dpyinfo->display=0, so the
above doesn't run, and the fonts leak.
I'm attaching a plot where I sampled the memory usage every second. At
the start I had an extra client window open, and we leak memory. Then I
closed that client window, and we started leaking memory much faster.
Then I created an extra client window again, and the leak slowed down
once again.
If we can fix the X error, the leak maybe doesn't matter.
[-- Attachment #2: memory_test.pdf --]
[-- Type: application/pdf, Size: 13044 bytes --]
next reply other threads:[~2015-09-18 4:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 4:41 Dima Kogan [this message]
[not found] ` <handler.21509.B.14425512741008.ack@debbugs.gnu.org>
2015-10-02 7:32 ` bug#21509: update Dima Kogan
2017-09-03 10:15 ` bug#21509: 25.0.50; X11 error: BadPixmap when creating first emacsclient frame; and memory leak martin rudalics
2017-09-05 6:21 ` Dima Kogan
2017-09-05 8:18 ` martin rudalics
2017-09-09 1:49 ` Dima Kogan
2017-09-09 7:59 ` martin rudalics
2017-10-15 3:48 ` Dima Kogan
2017-10-15 9:40 ` martin rudalics
2017-10-15 18:24 ` Dima Kogan
2017-10-16 7:42 ` martin rudalics
2017-10-16 16:33 ` Dima Kogan
2017-10-17 8:58 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877fno9w6b.fsf@secretsauce.net \
--to=dima@secretsauce.net \
--cc=21509@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.