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: Tue, 05 Sep 2017 10:18:25 +0200 Message-ID: <59AE5DD1.9050602@gmx.at> References: <877fno9w6b.fsf@secretsauce.net> <59ABD636.3070302@gmx.at> <87wp5d8y37.fsf@scrawny> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1504599591 15192 195.159.176.226 (5 Sep 2017 08:19:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Sep 2017 08:19:51 +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 Tue Sep 05 10:19:37 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 1dp94m-0002O6-Qv for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Sep 2017 10:19:17 +0200 Original-Received: from localhost ([::1]:57373 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dp94t-0006AA-Vj for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Sep 2017 04:19:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dp94h-00067S-UK for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 04:19:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dp94Y-0008V2-O2 for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 04:19:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41507) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dp94Y-0008Ua-KB for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 04:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dp94Y-0005ye-79 for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 04:19: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: Tue, 05 Sep 2017 08:19: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.150459952522952 (code B ref 21509); Tue, 05 Sep 2017 08:19:02 +0000 Original-Received: (at 21509) by debbugs.gnu.org; 5 Sep 2017 08:18:45 +0000 Original-Received: from localhost ([127.0.0.1]:50187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dp94G-0005y8-Nm for submit@debbugs.gnu.org; Tue, 05 Sep 2017 04:18:44 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:55388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dp94F-0005xu-2i for 21509@debbugs.gnu.org; Tue, 05 Sep 2017 04:18:43 -0400 Original-Received: from [192.168.1.100] ([46.125.249.7]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MPUlV-1dtnlA1GSH-004mDK; Tue, 05 Sep 2017 10:18:33 +0200 In-Reply-To: <87wp5d8y37.fsf@scrawny> X-Provags-ID: V03:K0:bpijuqsDffAgNtkkinr6ZVS2zKxlNuLm7LeDaBmhW/qv6oHZf+p d9wozSHCx2uCNqwYmjRxN+eRinkbpnZ4wChCk2jpRN5uMNMSRSz/nL82fgphhz72Yz0gykm Dl4HnOwoAQz94xiHUkPXrYNAzyCDQ2yEUNesPem+QPAcKyozSOo810J6HczZYUzEKU5d1X3 KxGEckJ4wtOrryq9pLpRA== X-UI-Out-Filterresults: notjunk:1;V01:K0:YzVZT+uuF78=:MCZBM83pt0Yw+7L5sARJAg lx9DA0ymCO+fwWYn4o4mID8b0CY6uGrjOVlYBXXYIeip0FHB+qXDaHUJdW7pMDZZlntBfGwi9 DxbXLUPLi+HQB4cI05CI1XIwsgmd/bawBuSA+AHZzhtAqFhvBWSeylpILlOliWRCqixgODW9N CImxX3gajwZrf5CSvwi+2EoUQACGks1rm3Hacc3H+rjTa07kLI2J4JWbq88oTRoVJOgaGDyjz D0wCrtHABcZy0goqvU8M8cTeozZ/eeZv9qv5xwK5kK/EwDelxN6fBHkMAhUPPEryvaMzolW9X xE0gtL0neQd7fHD9m7K9P4RhPtP4SCKh1nl4c64qvzMBjUcFR+fwzkJRaYVjzRLjQFbH67og8 FGgvRKmRHiVp48a9eZwonRDbzdE4UZaQe2DaPswCnO8RW//vV4L2J41QuhEk6hLemeK+iANQ+ tf4gJAaLrZtgMbxMVCcp91OlT0lLhZRqWQcH9nQ6qIbZRObJOrxfJhnkyvj0OBlF1Yu0GH720 HeqBLwWRyvO9PknGBynjWrAAfNgQGJ5EorvDRsZU0LdbzKuOMVKYtu9OW6Ew//UGgTHPSqpa9 fvtScIh+62ltGbGy3v/1qLa2RRhia+VweYvA2WpnfDqjL7FCGPiIHaBli203smikltkG9O8VF uGQLhDdFahNhr2P2UZlpf/ZuEd5mQ39htKyJ96zuHcTt2N1GFNFwqSHOPdcE6asneKw5rnBfe mxbCEhSdJwB2RYjZPYrOTBfROjRtrP9jIW9IsNZruKwCzhbGiLbfdtGU7M/B/rED1I7dvEsj 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:136597 Archived-At: > So in the case of lucid widgets, you not only fixed the bug, I coin it a "fix" because I just pushed the same workaround that had been used for the GTK build before. But it hardly qualifies as a real fix because it makes the referencing counting mechanism practically obsolete for any kind of frame deletion. > but also > massively plugged the memory leaks that were associated with new emacs= > frames. Awesome! IIUC your numbers of Lucid with scrollbars now coincide with the numbers of Lucid without scrollbars before the "fix". 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. > 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=3D450 in the gtk run. This= > asks malloc to return the the kernel all the unused memory it's holdin= g. > And we see a 5MB drop. So the GTK leaks aren't as bad as they look. I think what was going on before the "fix" is this: We free data we shouldn't, probably due to a bug in the reference counting mechanism. Some time later, after that data got overwritten, the new data triggers the error in the toolkit code. I say "some time later" because the error (1) apparently nowhere triggers with _every_ invocation of emacsclient, (2) its frequency seems to differ according to the various bug reports from every third invocation to every fifth, and (3) it seems to have a fairly constant frequency, at least here when it starts to happen every third invocation it will continue to happen every third invocation. While the above tries to explain the bug reported by the toolkit, any memory leak should follow from trying to delete the terminal but when doing so we forget to explicitly free some (maybe font related) data and when invoking a new client we reallocate that data instead of reusing the one we forgot about. 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? Also, could you try whether changing =E2=80=98gc-cons-threshold=E2=80=99 = 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. Thanks, martin