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

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

> 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.

Callers of android_exception_check assume that the preceding call(s) to
Java never signal exceptions, so that if an exception is signaled, it
must be an OOM error.  This assumption is made to avoid type comparisons
or local reference allocation (both of which may culminate in more OOM
errors) that would otherwise be necessary to establish the real cause of
an exception.

When an exception is registered by android_exception_check, it makes an
attempt to print it to the log buffer.  Piping it to `grep -A10
"Possible out of memory error"' should uncover the Java stack trace
saved in the exception.