From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#21509: 25.0.50; X11 error: BadPixmap when creating first emacsclient frame; and memory leak Date: Sat, 09 Sep 2017 09:59:50 +0200 Message-ID: <59B39F76.2010508@gmx.at> References: <877fno9w6b.fsf@secretsauce.net> <59ABD636.3070302@gmx.at> <87wp5d8y37.fsf@scrawny> <59AE5DD1.9050602@gmx.at> <87vaks8wul.fsf@scrawny> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1504944096 24919 195.159.176.226 (9 Sep 2017 08:01:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 9 Sep 2017 08:01:36 +0000 (UTC) Cc: 21509@debbugs.gnu.org To: Dima Kogan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 09 10:01:28 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqahZ-0005cG-Fy for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Sep 2017 10:01:17 +0200 Original-Received: from localhost ([::1]:48593 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqahg-0008Vz-MO for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Sep 2017 04:01:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqahN-0008Ki-OX for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 04:01:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqahK-0002CA-ML for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 04:01:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48133) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dqahK-0002Bc-IA for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 04:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dqahK-0004D4-4Q for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 04:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Sep 2017 08:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21509 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21509-submit@debbugs.gnu.org id=B21509.150494400516040 (code B ref 21509); Sat, 09 Sep 2017 08:01:02 +0000 Original-Received: (at 21509) by debbugs.gnu.org; 9 Sep 2017 08:00:05 +0000 Original-Received: from localhost ([127.0.0.1]:56809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqagP-0004Ae-A2 for submit@debbugs.gnu.org; Sat, 09 Sep 2017 04:00:05 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:49394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqagM-00049d-OM for 21509@debbugs.gnu.org; Sat, 09 Sep 2017 04:00:04 -0400 Original-Received: from [192.168.1.100] ([46.125.249.16]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M3iU5-1dYeBl49Nh-00rJ16; Sat, 09 Sep 2017 09:59:53 +0200 In-Reply-To: <87vaks8wul.fsf@scrawny> X-Provags-ID: V03:K0:UnVyNcoe7xnKaI2D0TFG1TsXcONgB6Q4BRtKWornSmYS7eJh3r6 i3VQppN4DMAFO5366+h252mmCyzYpMawOY0t7CbEQbuTWoOuXE9wBIb6FLHksjUP+lIVD/O 5bDt2BRG7EYiUEnFcNIML1zTJunHaLN2kbWvZtMo/Gj+J7lgkmotX573Hf8MxniF6s/+UzQ kvXa+dacy5H3ChYCwp8pQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:54L6rLrVHZI=:wkDCxVXJwah6qy/Uttgpcu GnfrWgRZ2FDbVZyMlzA0O6Qp1sv1urWlTPEd2cW6srw2A/SvX0B/5ggItb/w6henDQWtvWYse ZDf1Rg9mS5VWJwPcwsD1lE7Z3PYen4qqoMQNI3cpWerCUEoGQ70MA/GhBNZ0GxHkO+8gDzFsM MZHgEEkg+jg0eNquvrPn2u+gYN6ZPU2Hflga8Gt9vFJ9bkwM/YPUjCCQGAnD13Lr/aREBFlWh 0uRQJsXgXnMblG1cltHqPwwU7LWNw3jxKFw8Z+fthsN8iJce8kB0dA/mLs0LJ5gszxpy7mwps m9G7RTOH/QM1PZvD+W7u9KsovlONUy9CB1WGGkP71mMLTxam6SFJ64gOuv50ljsLAFJjMXM8E ytST7OfAr/AppX+IyePSgLvfpYjtOlF6IRdi5A9wx6G3g783Brth3X7XsovBjEbJYbBCUoKBB 7y+lIXkIMHgmb/x666q/JRVVFb0ysnrp2wH+6YjmHa4wMTRdtzbOKWF0wcm8LAHm+a1kYvxT2 NIcQZK+Ki9xnWs0iVEX8S5NZZASwQfmc2DUX+B4xpQC2ox2foq/cp7XQK4cXABrN+GjwkSisi 4AcMh1tbB8Ujit9h7y7F9RvIHlGZHTQHlVynttoE4+edWdDNSYXOKEByIkUlXvUyqFLwG2Z6l PRd7n0xuo7CxvEK5Q9Shw9YywKn1B7XLJuGu+1NhHZLiXBcgrYPOnHzqcyvI8CxTfIcUTnnQq i3Q0/VrS6yvWxe9tyjE0d5/HdMaVcrEpEjo3LMzIU9fI5dfdEIu/uXPg29TefAI8JOC8AQD4 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136698 Archived-At: >> IIUC your numbers of Lucid with scrollbars now coincide with the numbers >> of Lucid without scrollbars before the "fix". > > No, that's not right. > > Lucid with scrollbars post-fix is the blue line: memory usage is stable > as frames are created/destroyed: the leak is ~0 > > Lucid without scrollbars pre-fix is the green line. Memory usage is > climbing. We aren't leaking as badly as the other cases, but we ARE > leaking. > > So the fix resolved the large leakages in the other cases and also the > small leakages that weren't scroll-bar-related. I can't follow you. before.no.scroll.log has 16112 19608 S ? 00:00:00 emacs ... 16112 29700 S ? 00:00:12 emacs while after.yes.scroll.log has 17508 19652 S ? 00:00:00 emacs ... 17508 29160 S ? 00:00:13 emacs which strike me as very similar (especially given the figures of the two other logs). What am I missing? >> OTOH the numbers for GTK largely coincide with those of Lucid with >> scrollbars before the "fix". So X itself seems much more dominant than >> any toolkit particularities. > > I don't think this is right either. Lucid with scrollbars pre-fix is the > purple line. We leak memory at a high, constant rate. GTK memory usage > (yellow) is noisy and fragmented (I bet we're invoking malloc/free much > more often). The baseline memory consumption is higher, the past that, > the leak rate isn't nearly as bad as the purple. The higher > fragmentation means that the internals of malloc() matter too: I invoked > malloc_trim() just after t=450s, and we see the memory usage dropped > sharply as a result. I can't tell that since it's not in your figures. But again, the raw data from before.log and after.yes.scroll.gtk.log seem similar too. >> This does not explain any difference between the GTK (before the "fix") >> and Lucid (after the "fix") behaviors. What happens with GTK when you >> allow it to delete the terminal by allowing terminal->reference_count >> drop to zero? If it does not crash immediately, is the memory leak more >> heavy than it is now? > > I haven't run that experiment, but I could do that. Probably won't get > to it for a week, though. Please try. If you succeed running it, the resulting difference between the "before" GTK and Lucid runs should IMHO show the noise introduced by malloc/free more clearly. And obviously running the before/after experiments for Motif would be interesting too: The Motif build crashed in the menu bar section while the Lucid build crashed in the scroll bar section. >> Also, could you try whether changing gc-cons-threshold in either >> direction has any impact on the occurrence of the toolkit bug or the >> growth of the memory leak? Once I thought that this could affect the >> frequency of the error but didn't get any conclusive results. > > OK. I'll look. > > By the way, if you haven't tried it yet, look at rr: > > http://www.rr-project.com It's http://www.rr-project.org now. > It's a debugging instrumentation tool that saves a process execution > trace, and lets you replay it forwards and backwards in gdb. Could make > it possible to find heisen-problems such as this. If it's a GC related problem, it would need more patience than I'm able to provide anyway. I'm still trying to find a common pattern for all these behaviors from a coarse-grained perspective. And obviously it would be interesting to find out why the whereabouts at the time of the "X11 error that blows up the window" apparently differ for the various builds. IIUC it's still us who determine which one to draw first - the menu bar or the scroll bar. martin