bug-gnu-emacs
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]