[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65445: 29.1; Android emacs: False memory full condition, due to Java
From: |
Johan Widén |
Subject: |
bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?) |
Date: |
Mon, 21 Aug 2023 22:46:13 +0200 |
User-agent: |
mu4e 1.10.5; emacs 29.1 |
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
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?),
Johan Widén <=
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Po Lu, 2023/08/21
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Eli Zaretskii, 2023/08/21
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Po Lu, 2023/08/21
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Johan Widén, 2023/08/22
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Po Lu, 2023/08/22
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Johan Widén, 2023/08/22
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Po Lu, 2023/08/22
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Johan Widén, 2023/08/22
- bug#65445: 29.1; Android emacs: False memory full condition, due to Java exception (?), Po Lu, 2023/08/22