GNU bug report logs -
#55870
GNU Emacs 26.3, Select All(C-x h) does not work
Previous Next
To reply to this bug, email your comments to 55870 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Thu, 09 Jun 2022 14:33:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Bruce <brucelam1982pi <at> anche.no>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 09 Jun 2022 14:33:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
When editing chinese-book.txt(in attachment), I use (C-x h) to select
all,
GNU Emacs 26.3 only shows "mark set", then I use M-w to copy, it stops
working.
I try this on both Linux Mint 20.2, Debian 11.3, same error.
Please use GNU Emacs in you computer to test chinese-book.txt and debug.
Thanks a lot, :-)
Best Regards,
Bruce
[chinese-book.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Thu, 09 Jun 2022 14:58:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Bruce <brucelam1982pi <at> anche.no> writes:
> When editing chinese-book.txt(in attachment), I use (C-x h) to
> select all,
> GNU Emacs 26.3 only shows "mark set", then I use M-w to copy, it stops
> working.
I'm unable to reproduce this. Do you use any kind of package to manage
selections, by any chance? Can you reproduce this if you start Emacs
with -Q?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 09 Jun 2022 14:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Thu, 09 Jun 2022 16:17:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 9 Jun 2022 16:50:19 +0800
> From: Bruce via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> When editing chinese-book.txt(in attachment), I use (C-x h) to select
> all,
> GNU Emacs 26.3 only shows "mark set", then I use M-w to copy, it stops
> working.
>
> I try this on both Linux Mint 20.2, Debian 11.3, same error.
I cannot reproduce this.
What do you mean by "stops working"? what happens?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Fri, 10 Jun 2022 12:46:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 55870 <at> debbugs.gnu.org (full text, mbox):
(Resending with the debbugs address in the CC so that it lands in the
bug tracker.)
Bruce <brucelam1982pi <at> anche.no> writes:
> Thanks, :-)
>
> Editing chinese-book.txt(in attachment), I use (C-x h) to select all,
> GNU Emacs 26.3 only shows "mark set", then I use M-w to copy,
> The memory that Emacs consumes jumps from 80MB to 1000MB, then it
> does not
> responds to keyboard or mouse.
>
> Now I use emacs -mm, I will try emacs -Q
>
> On 2022/6/9 下午10:57, Lars Ingebrigtsen wrote:
>> Bruce <brucelam1982pi <at> anche.no> writes:
>>
>>> When editing chinese-book.txt(in attachment), I use (C-x h) to
>>> select all,
>>> GNU Emacs 26.3 only shows "mark set", then I use M-w to copy, it stops
>>> working.
>> I'm unable to reproduce this. Do you use any kind of package to manage
>> selections, by any chance? Can you reproduce this if you start Emacs
>> with -Q?
>>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Mon, 11 Jul 2022 11:02:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Editing chinese-book.txt(in attachment), I use (C-x h) to select all,
>> GNU Emacs 26.3 only shows "mark set", then I use M-w to copy,
>> The memory that Emacs consumes jumps from 80MB to 1000MB, then it
>> does not
>> responds to keyboard or mouse.
>>
>> Now I use emacs -mm, I will try emacs -Q
This was a month ago -- did you manage to reproduce the issue with
"emacs -Q"?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Tue, 12 Jul 2022 12:12:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 55870 <at> debbugs.gnu.org (full text, mbox):
(Please keep the debbugs address in the CCs -- otherwise it won't reach
the bug tracker.)
Bruce <brucelam1982pi <at> anche.no> writes:
> -- This was a month ago -- did you manage to reproduce the issue with
> -- "emacs -Q"?
>
> Thanks for your remind, :-)
>
> I reproduce the issue with "emacs -Q" as described in email title
> 'Re: bug#55870: GNU Emacs 26.3, Select All(C-x h) does not work'
> on 2022-06-12. Here was the content (you can search your mail inbox)
>
> Under Linux Mint 20.2 and Debian 11.3
>
> 1. Using emacs -Q or emacs -mm, editing chinese-book.txt(in attachment)
> 2. (C-x h) to select all, GNU Emacs 26.3 only shows "mark set",
> 3. I use M-w to copy, The memory that Emacs consumes jumps from around
> 80MB to
> 1000MB even 1400MB, then it does not responds to keyboard or mouse.
Can you reproduce the problem in a more recent version of Emacs? 26.3
is several years old.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Wed, 13 Jul 2022 06:18:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 55870 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Can you reproduce the problem in a more recent version of Emacs? 26.3
> is several years old.
I reproduce the problem in emacs 28.1. Please refer to the attachments.
Please fix it, thanks, :-)
On 2022/7/12 下午8:11, Lars Ingebrigtsen wrote:
> (Please keep the debbugs address in the CCs -- otherwise it won't reach
> the bug tracker.)
>
> Bruce <brucelam1982pi <at> anche.no> writes:
>
>> -- This was a month ago -- did you manage to reproduce the issue with
>> -- "emacs -Q"?
>>
>> Thanks for your remind, :-)
>>
>> I reproduce the issue with "emacs -Q" as described in email title
>> 'Re: bug#55870: GNU Emacs 26.3, Select All(C-x h) does not work'
>> on 2022-06-12. Here was the content (you can search your mail inbox)
>>
>> Under Linux Mint 20.2 and Debian 11.3
>>
>> 1. Using emacs -Q or emacs -mm, editing chinese-book.txt(in attachment)
>> 2. (C-x h) to select all, GNU Emacs 26.3 only shows "mark set",
>> 3. I use M-w to copy, The memory that Emacs consumes jumps from around
>> 80MB to
>> 1000MB even 1400MB, then it does not responds to keyboard or mouse.
> Can you reproduce the problem in a more recent version of Emacs? 26.3
> is several years old.
>
[chinese-book.txt (text/plain, attachment)]
[emacs-bug-01.png (image/png, attachment)]
[emacs-bug-02.png (image/png, attachment)]
[emacs-bug-03.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Wed, 13 Jul 2022 10:57:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Bruce <brucelam1982pi <at> anche.no> writes:
> I reproduce the problem in emacs 28.1. Please refer to the attachments.
> Please fix it, thanks, :-)
Like I said, I'm not able to reproduce the problem. The file doesn't
even come up as Chinese when opening it with "emacs -Q
chinese-book.txt", so there's some additional steps needed to reproduce
the problem.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Wed, 13 Jul 2022 11:14:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 55870 <at> debbugs.gnu.org (full text, mbox):
[Wednesday July 13, 2022] Lars Ingebrigtsen wrote:
> The file doesn't even come up as Chinese when opening it with "emacs
> -Q chinese-book.txt", so there's some additional steps needed to
> reproduce the problem.
If I switch to the Chinese-GB environment and revert the buffer, some
Chinese text shows up here.
Options > Multilingual Environment > Set Language Environment > Chinese > Chinese-GB
I tried M-w a couple of times, but the memory usage before and after
didn't change much (the Mem number in proced didn't go up by much)
here's `free -h' before and after M-w M-w:
Before:
total used free shared buff/cache available
Mem: 3.7Gi 1.3Gi 905Mi 125Mi 1.5Gi 2.1Gi
Swap: 4.0Gi 715Mi 3.3Gi
After:
total used free shared buff/cache available
Mem: 3.7Gi 1.3Gi 897Mi 130Mi 1.6Gi 2.1Gi
Swap: 4.0Gi 715Mi 3.3Gi
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Wed, 13 Jul 2022 11:44:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> Cc: 55870 <at> debbugs.gnu.org
> Date: Wed, 13 Jul 2022 11:01:55 +0800
> From: Bruce via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > Can you reproduce the problem in a more recent version of Emacs? 26.3
> > is several years old.
>
> I reproduce the problem in emacs 28.1. Please refer to the attachments.
After you visit the file, what does Emacs say if you type
M-: buffer-file-coding-system RET
Also, the image you show says in the mode line
Top of 219k (1,0) 10:32xxx 0.92
which is not what I'd expect from "emacs -Q". So I think there are
some local changes or customizations in your Emacs that perhaps are
part of the issue somehow. Please tell more about this build of Emacs
and how you invoke it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Thu, 14 Jul 2022 10:03:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Bruce <brucelam1982pi <at> anche.no> writes:
> I copy .emacs as emacs-bruce
>
> Please try emacs-bruce in the attachment. Thanks, :-)
Did you reproduce the problem with "emacs -Q" or with that .emacs file?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Thu, 14 Jul 2022 10:14:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 55870 <at> debbugs.gnu.org
> From: Bruce <brucelam1982pi <at> anche.no>
> Date: Thu, 14 Jul 2022 18:09:45 +0800
>
> Both options reproduce the problem in my GNU/Linux.
What about the question I asked:
> After you visit the file, what does Emacs say if you type
>
> M-: buffer-file-coding-system RET
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Thu, 14 Jul 2022 14:07:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 55870 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I copy .emacs as emacs-bruce
Please try emacs-bruce in the attachment. Thanks, :-)
On 2022/7/13 下午7:43, Eli Zaretskii wrote:
>> Cc: 55870 <at> debbugs.gnu.org
>> Date: Wed, 13 Jul 2022 11:01:55 +0800
>> From: Bruce via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> > Can you reproduce the problem in a more recent version of Emacs? 26.3
>> > is several years old.
>>
>> I reproduce the problem in emacs 28.1. Please refer to the attachments.
> After you visit the file, what does Emacs say if you type
>
> M-: buffer-file-coding-system RET
>
> Also, the image you show says in the mode line
>
> Top of 219k (1,0) 10:32xxx 0.92
>
> which is not what I'd expect from "emacs -Q". So I think there are
> some local changes or customizations in your Emacs that perhaps are
> part of the issue somehow. Please tell more about this build of Emacs
> and how you invoke it.
[emacs-bruce (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Thu, 14 Jul 2022 14:07:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Both options reproduce the problem in my GNU/Linux.
On 2022/7/14 下午6:02, Lars Ingebrigtsen wrote:
> Bruce <brucelam1982pi <at> anche.no> writes:
>
>> I copy .emacs as emacs-bruce
>>
>> Please try emacs-bruce in the attachment. Thanks, :-)
> Did you reproduce the problem with "emacs -Q" or with that .emacs file?
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Fri, 15 Jul 2022 13:04:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
> From: Bruce <brucelam1982pi <at> anche.no>
> Date: Fri, 15 Jul 2022 20:44:59 +0800
>
> buffer-file-coding-system is a variable defined in ‘C source code’.
> Its value is ‘chinese-gbk-unix’
> Local in buffer chinese-book.txt; global value is utf-8-unix
OK, thanks.
And is this a GUI session or a text-mode session? That is, what is
the value of the variable window-system?
Also, what is the value of the variable selection-coding-system?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Fri, 15 Jul 2022 15:24:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 55870 <at> debbugs.gnu.org (full text, mbox):
buffer-file-coding-system is a variable defined in ‘C source code’.
Its value is ‘chinese-gbk-unix’
Local in buffer chinese-book.txt; global value is utf-8-unix
On 2022/7/14 下午6:13, Eli Zaretskii wrote:
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 55870 <at> debbugs.gnu.org
>> From: Bruce <brucelam1982pi <at> anche.no>
>> Date: Thu, 14 Jul 2022 18:09:45 +0800
>>
>> Both options reproduce the problem in my GNU/Linux.
> What about the question I asked:
>
>> After you visit the file, what does Emacs say if you type
>>
>> M-: buffer-file-coding-system RET
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sat, 16 Jul 2022 00:24:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 55870 <at> debbugs.gnu.org (full text, mbox):
window-system is a variable defined in ‘C source code’.
Its value is ‘x’
It is a terminal-local variable; global value is the same.
selection-coding-system is a variable defined in ‘select.el’.
Its value is nil
On 2022/7/15 下午9:03, Eli Zaretskii wrote:
>> Cc: larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
>> From: Bruce <brucelam1982pi <at> anche.no>
>> Date: Fri, 15 Jul 2022 20:44:59 +0800
>>
>> buffer-file-coding-system is a variable defined in ‘C source code’.
>> Its value is ‘chinese-gbk-unix’
>> Local in buffer chinese-book.txt; global value is utf-8-unix
> OK, thanks.
>
> And is this a GUI session or a text-mode session? That is, what is
> the value of the variable window-system?
>
> Also, what is the value of the variable selection-coding-system?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sat, 16 Jul 2022 05:39:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
> From: Bruce <brucelam1982pi <at> anche.no>
> Date: Sat, 16 Jul 2022 08:15:55 +0800
>
> window-system is a variable defined in ‘C source code’.
> Its value is ‘x’
> It is a terminal-local variable; global value is the same.
>
> selection-coding-system is a variable defined in ‘select.el’.
> Its value is nil
Thanks. And what does the below report?
M-: (default-value 'selection-coding-system) RET
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 06:39:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
> From: Bruce <brucelam1982pi <at> anche.no>
> Date: Sun, 17 Jul 2022 10:38:25 +0800
>
> (default-value 'selection-coding-system)
>
> reports: nil
Maybe this is the reason. Po Lu, what data-type do we use on X to put
data into the clipboard when the user presses M-w?
> What functions do emacs call after I press Meta-w?
There are too many of them to mention here. In general, Emacs saves
the text on the kill-ring and also puts it into the X clipboard.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 07:28:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Maybe this is the reason. Po Lu, what data-type do we use on X to put
> data into the clipboard when the user presses M-w?
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. Normally, it is UTF8_STRING for
UTF-8 data, COMPOUND_TEXT for X compound text data, STRING for
iso-latin-1, and C_STRING for raw text.
selection-coding-system should not be set under X, since the semantics
are very confusing. Simple example: when selection-coding-system is set
to utf-8-dos, Emacs will respond to requests for UTF8_STRING with text
encoded with utf-8-dos, but requests for STRING will still be Latin-1.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 07:53:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Bruce <brucelam1982pi <at> anche.no>, larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
> Date: Sun, 17 Jul 2022 15:27:12 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Maybe this is the reason. Po Lu, what data-type do we use on X to put
> > data into the clipboard when the user presses M-w?
>
> 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"?
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 08:42:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> 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.
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 10:09:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: brucelam1982pi <at> anche.no, larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
> Date: Sun, 17 Jul 2022 16:41:21 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 11:58:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> 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?
The previous value of the selection will also be removed from
terminal->Vselection_alist, so it shouldn't cause memory usage to
constantly increase.
> Can any of the potential requests in this situation allocate lots of
> memory?
Yes. The string is copied each time another program requests the
selection, and we have to allocate a buffer the size of the encoded X
property data each time we want to send it to another client.
But unfortunately I can't see any obvious memory leak here. The
reporter should build with TRACE_SELECTION and send some of the output,
which could reveal, for example, bugs in the other program (possibly a
clipboard manager, since clipboard managers are a known problematic area
in the X world) that the code in xselect.c doesn't already take into
account.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 12:50:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 55870 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: brucelam1982pi <at> anche.no, larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
> Date: Sun, 17 Jul 2022 19:57:20 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > 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?
>
> The previous value of the selection will also be removed from
> terminal->Vselection_alist, so it shouldn't cause memory usage to
> constantly increase.
>
> > Can any of the potential requests in this situation allocate lots of
> > memory?
>
> Yes. The string is copied each time another program requests the
> selection, and we have to allocate a buffer the size of the encoded X
> property data each time we want to send it to another client.
>
> But unfortunately I can't see any obvious memory leak here. The
> reporter should build with TRACE_SELECTION and send some of the output,
> which could reveal, for example, bugs in the other program (possibly a
> clipboard manager, since clipboard managers are a known problematic area
> in the X world) that the code in xselect.c doesn't already take into
> account.
Bruce, can you build Emacs with that option enabled and provide us
with the traces?
Also, do you have some software installed on your system that could
automatically request the clipboard contents when Emacs puts text
there? If so, perhaps disabling that software will resolve the
problem.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 13:08:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 55870 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Bruce, can you build Emacs with that option enabled and provide us
> with the traces?
BTW, if it wasn't already clear, to do that simply place this line:
#define TRACE_SELECTION
at the top of src/xselect.c before building Emacs.
Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Sun, 17 Jul 2022 15:04:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 55870 <at> debbugs.gnu.org (full text, mbox):
(default-value 'selection-coding-system)
reports: nil
What functions do emacs call after I press Meta-w?
It seems they copy a lot of junks to the memory
(copying one 424KByte file occupies 5.9GByte system memory)
On 2022/7/16 下午1:37, Eli Zaretskii wrote:
>> Cc: larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
>> From: Bruce <brucelam1982pi <at> anche.no>
>> Date: Sat, 16 Jul 2022 08:15:55 +0800
>>
>> window-system is a variable defined in ‘C source code’.
>> Its value is ‘x’
>> It is a terminal-local variable; global value is the same.
>>
>> selection-coding-system is a variable defined in ‘select.el’.
>> Its value is nil
> Thanks. And what does the below report?
>
> M-: (default-value 'selection-coding-system) RET
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Mon, 18 Jul 2022 01:47:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 55870 <at> debbugs.gnu.org (full text, mbox):
>Bruce, can you build Emacs with that option enabled and provide us
>with the traces?
Enable that option in configure before "make" and "make install"?
Steps to trace it after new build?
>Also, do you have some software installed on your system that could
>automatically request the clipboard contents when Emacs puts text
>there?
I will check.
Thanks, :-)
On 2022/7/17 下午8:49, Eli Zaretskii wrote:
>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: brucelam1982pi <at> anche.no, larsi <at> gnus.org, 55870 <at> debbugs.gnu.org
>> Date: Sun, 17 Jul 2022 19:57:20 +0800
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> 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?
>> The previous value of the selection will also be removed from
>> terminal->Vselection_alist, so it shouldn't cause memory usage to
>> constantly increase.
>>
>>> Can any of the potential requests in this situation allocate lots of
>>> memory?
>> Yes. The string is copied each time another program requests the
>> selection, and we have to allocate a buffer the size of the encoded X
>> property data each time we want to send it to another client.
>>
>> But unfortunately I can't see any obvious memory leak here. The
>> reporter should build with TRACE_SELECTION and send some of the output,
>> which could reveal, for example, bugs in the other program (possibly a
>> clipboard manager, since clipboard managers are a known problematic area
>> in the X world) that the code in xselect.c doesn't already take into
>> account.
> Bruce, can you build Emacs with that option enabled and provide us
> with the traces?
>
> Also, do you have some software installed on your system that could
> automatically request the clipboard contents when Emacs puts text
> there? If so, perhaps disabling that software will resolve the
> problem.
>
> Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Mon, 18 Jul 2022 01:47:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 55870 <at> debbugs.gnu.org (full text, mbox):
OK, Thanks, :-)
On 2022/7/17 下午9:07, Po Lu wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Bruce, can you build Emacs with that option enabled and provide us
>> with the traces?
> BTW, if it wasn't already clear, to do that simply place this line:
>
> #define TRACE_SELECTION
>
> at the top of src/xselect.c before building Emacs.
>
> Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55870
; Package
emacs
.
(Mon, 18 Jul 2022 01:47:03 GMT)
Full text and
rfc822 format available.
Message #94 received at 55870 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I rebuild emacs28.1 as you said, but it still reproduce the problem.
Please refer to the attachment.
2022-07-18 08時49分15秒 /home/bruce/bin/emacs-28.1/src bruce 2047$
head xselect.c
#define TRACE_SELECTION
/* X Selection processing for Emacs.
Copyright (C) 1993-1997, 2000-2022 Free Software Foundation, Inc.
This file is part of GNU Emacs.
GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
On 2022/7/17 下午9:07, Po Lu wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Bruce, can you build Emacs with that option enabled and provide us
>> with the traces?
> BTW, if it wasn't already clear, to do that simply place this line:
>
> #define TRACE_SELECTION
>
> at the top of src/xselect.c before building Emacs.
>
> Thanks in advance.
[2022-07-18_emacs-after-build-with-TRACE_SELECTION.png (image/png, attachment)]
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 15 Aug 2022 14:40:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 305 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.