From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#55870: GNU Emacs 26.3, Select All(C-x h) does not work Date: Sun, 17 Jul 2022 13:08:16 +0300 Message-ID: <834jzgqcfj.fsf@gnu.org> References: <2278e9bf-89e3-560d-52fc-f26a45aee36c@anche.no> <87zgil28bo.fsf@gnus.org> <1fc51cba-c767-2e5f-e0be-6e0f8d7d1df6@anche.no> <87mteku1q1.fsf@gnus.org> <87edyrykuf.fsf@gnus.org> <92253b43-50a1-554e-de66-f31f0c423b1f@anche.no> <875yk2sf82.fsf@gnus.org> <83edypw852.fsf@gnu.org> <6e8af953-d207-9912-dc12-254c88470e42@anche.no> <87cze8au6a.fsf@gnus.org> <1d401848-ecec-8233-9aa6-61e52253bc86@anche.no> <83ilo0t32m.fsf@gnu.org> <5d6164aa-42e2-8eda-f935-1b84dec835ec@anche.no> <83k08esf3v.fsf@gnu.org> <7349b51e-6d0b-94b1-d3fb-540d3c2256b5@anche.no> <837d4dsjm8.fsf@gnu.org> <697ffdfe-3827-dcc9-92d2-cf918a19e871@anche.no> <83a698qm67.fsf@gnu.org> <87wnccfbcf.fsf@yahoo.com> <837d4cqiqs.fsf@gnu.org> <87k08cf7wu.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55870@debbugs.gnu.org, larsi@gnus.org, brucelam1982pi@anche.no To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 17 12:10:05 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oD1Dw-0009ph-UJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Jul 2022 12:10:05 +0200 Original-Received: from localhost ([::1]:46060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oD1Dv-0006D6-AZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Jul 2022 06:10:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oD1Cx-0005H1-De for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2022 06:09:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48988) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oD1Cw-0001mx-Bh for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2022 06:09:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oD1Cw-0006Yy-2U for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2022 06:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Jul 2022 10:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55870 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 55870-submit@debbugs.gnu.org id=B55870.165805252125198 (code B ref 55870); Sun, 17 Jul 2022 10:09:02 +0000 Original-Received: (at 55870) by debbugs.gnu.org; 17 Jul 2022 10:08:41 +0000 Original-Received: from localhost ([127.0.0.1]:46747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oD1Cb-0006YK-3f for submit@debbugs.gnu.org; Sun, 17 Jul 2022 06:08:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oD1CY-0006Y8-VS for 55870@debbugs.gnu.org; Sun, 17 Jul 2022 06:08:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43960) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oD1CS-0001kX-H1; Sun, 17 Jul 2022 06:08:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=q0GN14DvRJgZXtrNx49o/VH9LSmJXlykgqHfb1cxrMg=; b=E/N9ISTH+pl7 Lk+M3K0Wui5pHRVVkv00wNlQVKBpW3fuOvO6IiURaJw4FXSOAQEgMh9zt/D9K3yze9sBsIny6+MJw JeC+8prtaIQa8aBVAVlcUUe27wLcfg+Sz0SiyPZSwVoaisNgVrC8eChpXpd5K3YyeLdijmUVn45Yb QEbv775rSgYuAfx3Udg2fMJV+uaiL8sAJmucsVIP/2G4jEJSBZ009cZZS3J8qDt6174Ehiz5sCJd7 5ThLEd+oz/MK5jQK0y0NKFvwCy06XtiVZapF3XL2/MUGkb4/lVNLYpVwH/S7oAmwpm4t3OG73nXPA L8kBOhydVUaTEWqk6CbgIg==; Original-Received: from [87.69.77.57] (port=2055 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oD1CS-0005si-09; Sun, 17 Jul 2022 06:08:32 -0400 In-Reply-To: <87k08cf7wu.fsf@yahoo.com> (message from Po Lu on Sun, 17 Jul 2022 16:41:21 +0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237252 Archived-At: > From: Po Lu > Cc: brucelam1982pi@anche.no, larsi@gnus.org, 55870@debbugs.gnu.org > Date: Sun, 17 Jul 2022 16:41:21 +0800 > > Eli Zaretskii writes: > > >> None in particular: we store the clipboard data locally, and other > >> programs request different selection "targets" from Emacs depending on > >> the coding system they want it in. > > > > So the memory growth in the OP's scenario is due to something we do > > locally? Where's the code which "stores the clipboard data locally"? > > xselect.c. Look at the code which changes terminal->Vselection_alist in > x_own_selection. So the growing memory can only be explained by the consing of selection_value onto terminal->Vselection_alist, where selection_value is the text being copied by M-w? > > Or maybe some external program does request the clipboard data on OP's > > machine? Is there a way to know when that happens, and specifically > > to know which data-type is being requested? > > The best way is to build xselect.c with TRACE_SELECTION defined to 1 in > that file. Otherwise, tracing each of the functions in > selection-converter-alist should work too, but will not catch requests > for types Emacs does not know how to handle. Can any of the potential requests in this situation allocate lots of memory? (I'm at the end of my wits here, and very close to declare this bug as not reproducible, so any ideas for debugging it further are welcome.)