GNU bug report logs - #65445
29.1; Android emacs: False memory full condition, due to Java exception (?)

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Johan Widén <j.e.widen <at> gmail.com>
Subject: bug#65445: closed (Re: bug#65445: 29.1; Android emacs: False
 memory full condition, due to Java exception (?))
Date: Sat, 02 Sep 2023 18:53:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?)

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 65445 <at> debbugs.gnu.org.

-- 
65445: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65445
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Johan Widén <j.e.widen <at> gmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, 65445-done <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#65445: 29.1; Android emacs: False memory full condition, due
 to Java exception (?)
Date: Sat, 2 Sep 2023 11:52:28 -0700

Johan Widén <j.e.widen <at> gmail.com> writes:

> Yes, it seems to be fixed. I can no longer provoke the bug.

Thanks, I'm therefore closing this bug.

[Message part 3 (message/rfc822, inline)]

From: Johan Widén <j.e.widen <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Android emacs: False memory full condition, due to Java
 exception (?)
Date: Mon, 21 Aug 2023 22:46:13 +0200

This bug report is for Android emacs, but I am writing it in my Ubuntu
emacs, so the config of the Ubuntu emacs is irrelevant. I can send the
Android emacs figures later, if so desired. I currently have Android
emacs connected to a debugger, with the stacktrace active, so for now I
would like to avoid executing report-emacs-bug there.

The following bug, or similar, have appeared in all Android emacs
versions that I have downloaded from Sourceforge. The latest was
downloaded 20-aug-2023 15:38 UTC.

I append a stacktrace. This is from my own build, but the only file
that is modifed relative to the repo is alloc.c where I have added 20
lines or so before the place where I triggered an abort(). I put an
abort() in memory full, as I so far have not been able to set
functioning break points.

What happens is that after some editing emacs reports that memory is
full. But (memory-info) and (memory-report) shows that there is a lot of
free memory. Emacs internal data allocation is about 150 megabyte, and
free memory is about 300 megabyte.

I will try to analyze the stack trace more, but I thought it might be of interest.
I can trigger the bug fairly repeatable, in the following manner: I use
spacemacs in evil mode. I start spacemacs and open a pdf book in
pdf-tools. I then split the window and open a (non empty) text file. At
the beginning of the text file I enter the evil commands: i0C-[yl
which inserts a '0' and then copies it to evils two 'yank' registers.
That is when the memory full condition occurs. I have triggered the bug
or a similar bug several times in other editing conditions, but I have
not been able to repeat those. It was a bit of phase of the moon.

    frame #1: 0x0000007b9d0cd304 libemacs.so`memory_full(nbytes=0) at alloc.c:4354:7
    frame #2: 0x0000007b9d20f4c4 libemacs.so`android_exception_check_1(object=0x000000000000004d) at android.c:5669:3
    frame #3: 0x0000007b9d240d34 libemacs.so`Fandroid_get_clipboard_data(type=0xb400007d2da9b964) at androidselect.c:386:3
    frame #4: 0x0000007b9d1125d0 libemacs.so`funcall_subr(subr=0x0000007b9d3d8868, numargs=1, args=0xb400007b94185480) at eval.c:3047:15
    frame #5: 0x0000007b9d16cfc4 libemacs.so`exec_byte_code(fun=0x0000007b95c2e245, args_template=257, nargs=1, args=0xb400007b94185450) at bytecode.c:815:14
    frame #6: 0x0000007b9d115ee8 libemacs.so`fetch_and_exec_byte_code(fun=0x0000007b95c2e015, args_template=514, nargs=2, args=0x0000007b99bec658) at eval.c:3094:10
    frame #7: 0x0000007b9d1129a4 libemacs.so`funcall_lambda(fun=0x0000007b95c2e015, nargs=2, arg_vector=0x0000007b99bec658) at eval.c:3166:9
    frame #8: 0x0000007b9d112324 libemacs.so`funcall_general(fun=0x0000007b95c2e015, numargs=2, args=0x0000007b99bec658) at eval.c:2958:12
    frame #9: 0x0000007b9d10de94 libemacs.so`Ffuncall(nargs=3, args=0x0000007b99bec650) at eval.c:3008:21
    frame #10: 0x0000007b9d1118a0 libemacs.so`Fapply(nargs=2, args=0xb400007b941853b8) at eval.c:2679:24
    frame #11: 0x0000007b9d1127bc libemacs.so`funcall_subr(subr=0x0000007b9d3d2208, numargs=2, args=0xb400007b941853b8) at eval.c:3072:9
    frame #12: 0x0000007b9d16cfc4 libemacs.so`exec_byte_code(fun=0x0000007b95a44385, args_template=770, nargs=3, args=0xb400007b94185630) at bytecode.c:815:14
    frame #13: 0x0000007b9d115ee8 libemacs.so`fetch_and_exec_byte_code(fun=0x0000007b957b18e5, args_template=513, nargs=1, args=0xb400007b941851f0) at eval.c:3094:10
    frame #14: 0x0000007b9d1129a4 libemacs.so`funcall_lambda(fun=0x0000007b957b18e5, nargs=1, arg_vector=0xb400007b941851f0) at eval.c:3166:9
    frame #15: 0x0000007b9d112324 libemacs.so`funcall_general(fun=0x0000007b957b18e5, numargs=1, args=0xb400007b941851f0) at eval.c:2958:12
    frame #16: 0x0000007b9d10de94 libemacs.so`Ffuncall(nargs=2, args=0xb400007b941851e8) at eval.c:3008:21
    frame #17: 0x0000007b9d1114f4 libemacs.so`Fapply(nargs=2, args=0xb400007b941851e8) at eval.c:2636:14
    frame #18: 0x0000007b9d1127bc libemacs.so`funcall_subr(subr=0x0000007b9d3d2208, numargs=2, args=0xb400007b941851e8) at eval.c:3072:9
    frame #19: 0x0000007b9d16cfc4 libemacs.so`exec_byte_code(fun=0xb400007d7d28d1b5, args_template=128, nargs=1, args=0xb400007b94185190) at bytecode.c:815:14
    frame #20: 0x0000007b9d115ee8 libemacs.so`fetch_and_exec_byte_code(fun=0xb400007d7ced0d05, args_template=1282, nargs=5, args=0x0000007b99bedd70) at eval.c:3094:10
    frame #21: 0x0000007b9d1129a4 libemacs.so`funcall_lambda(fun=0xb400007d7ced0d05, nargs=5, arg_vector=0x0000007b99bedd70) at eval.c:3166:9
    frame #22: 0x0000007b9d112324 libemacs.so`funcall_general(fun=0xb400007d7ced0d05, numargs=5, args=0x0000007b99bedd70) at eval.c:2958:12
-- 
Johan Widén, tel: +46705367346
Risvägen 5 A, 192 73 Sollentuna, SWEDEN

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.