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

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

[Johan Widén]

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 (?)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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

[Eli Zaretskii]

> Cc: 65445@debbugs.gnu.org
> Date: Tue, 22 Aug 2023 07:52:18 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 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.

Would it be useful to add this to etc/DEBUG?

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]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 65445@debbugs.gnu.org
>> Date: Tue, 22 Aug 2023 07:52:18 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> 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.
>
> Would it be useful to add this to etc/DEBUG?

Yes, I will do that.

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

[Johan Widén]

It seems that Android emacs copies to (and from?) the system clipboard
very often. This is not the case in other Android apps: There copy to
and from the system clipboard is a very explicit operation. Perhaps it
should be so also in Android emacs: Create a new set of elisp
functions for this, and initially only have them bound to a couple of
icons at the top of emacs. Perhaps also provide interaction using long
press.

When I do the evil yank, that is copy some text object to evil
registers, Android displays a pop up text that says the text has been
copied to the system clipboard.

If nothing else, I believe that removing the current connection of
internal copy paste, to system clipboard copy paste, would remove the
annoying "out of memory error".

Den tis 22 aug. 2023 kl 04:28 skrev Po Lu <luangruo@yahoo.com>:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Cc: 65445@debbugs.gnu.org
> >> Date: Tue, 22 Aug 2023 07:52:18 +0800
> >> From:  Po Lu via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >>
> >> 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.
> >
> > Would it be useful to add this to etc/DEBUG?
>
> Yes, I will do that.
>


-- 
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 (?)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> It seems that Android emacs copies to (and from?) the system clipboard
> very often.

This is in fact controlled by a user variable, like on other systems.
If you want to disable the clipboard, set select-enable-clipboard to
nil.

> If nothing else, I believe that removing the current connection of
> internal copy paste, to system clipboard copy paste, would remove the
> annoying "out of memory error".

I doubt that's actually an out-of-memory error, so would you please
follow the steps I previously outlined to obtain the exception's
backtrace for further analysis?

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

[Johan Widén]

I used emacs swiper to search for "out of memory" but found nothing.
This was in the dumpstate*.txt file fetched by
  adb bugreport org.gnu.emacs

Den tis 22 aug. 2023 kl 07:25 skrev Po Lu <luangruo@yahoo.com>:
>
> Johan Widén <j.e.widen@gmail.com> writes:
>
> > It seems that Android emacs copies to (and from?) the system clipboard
> > very often.
>
> This is in fact controlled by a user variable, like on other systems.
> If you want to disable the clipboard, set select-enable-clipboard to
> nil.
>
> > If nothing else, I believe that removing the current connection of
> > internal copy paste, to system clipboard copy paste, would remove the
> > annoying "out of memory error".
>
> I doubt that's actually an out-of-memory error, so would you please
> follow the steps I previously outlined to obtain the exception's
> backtrace for further analysis?



-- 
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 (?)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> I used emacs swiper to search for "out of memory" but found nothing.
> This was in the dumpstate*.txt file fetched by
>   adb bugreport org.gnu.emacs

Perhaps the log buffer has been rotated past the point of the error.
Also, I believe adb bugreport only includes log messages after a crash:
since Emacs is capable of recovering from these faux ``out of memory''
errors, the message printed may not appear within generated bug reports.

How about:

  (adb) logcat | grep -A10 "Possible out of memory"

?

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

[Johan Widén]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

I now ran
  adb logcat -d | grep ...
and got the enclosed log lines, which seems to be from today, not from
the time of my bug report.
But it is for emacs.

Den tis 22 aug. 2023 kl 08:51 skrev Po Lu <luangruo@yahoo.com>:
>
> Johan Widén <j.e.widen@gmail.com> writes:
>
> > I used emacs swiper to search for "out of memory" but found nothing.
> > This was in the dumpstate*.txt file fetched by
> >   adb bugreport org.gnu.emacs
>
> Perhaps the log buffer has been rotated past the point of the error.
> Also, I believe adb bugreport only includes log messages after a crash:
> since Emacs is capable of recovering from these faux ``out of memory''
> errors, the message printed may not appear within generated bug reports.
>
> How about:
>
>   (adb) logcat | grep -A10 "Possible out of memory"
>
> ?



-- 
Johan Widén, tel: +46705367346
Risvägen 5 A, 192 73 Sollentuna, SWEDEN

[-- Attachment #2: logcat.txt --]
[-- Type: text/plain, Size: 1479 bytes --]

08-22 07:42:57.956 16554 16597 W android_exception_check_1: Possible out of memory error.  The Java exception follows:  
08-22 07:42:57.956 16554 16597 W System.err: java.lang.NullPointerException: Attempt to invoke virtual method 'int android.content.ClipData.getItemCount()' on a null object reference
08-22 07:42:57.956 16554 16597 W System.err: 	at org.gnu.emacs.EmacsSdk11Clipboard.getClipboardData(EmacsSdk11Clipboard.java:247)
08-22 07:42:57.957 16554 16597 W System.err: 	at org.gnu.emacs.EmacsNative.initEmacs(Native Method)
08-22 07:42:57.957 16554 16597 W System.err: 	at org.gnu.emacs.EmacsThread.run(EmacsThread.java:80)
08-22 07:42:57.958 16554 16599 I android_run_debug_thread: libunwind: Unsupported .eh_frame_hdr version
08-22 07:42:57.960 16554 16599 I android_run_debug_thread: Backtrace:
08-22 07:42:57.960 16554 16599 I android_run_debug_thread: /apex/com.android.runtime/lib64/bionic/libc.so(backtrace+0x3c) [0x7f2698ce3c]
08-22 07:42:57.960 16554 16599 I android_run_debug_thread: /data/app/~~GwLIc-L9KJZNDVGvtbZXQw==/org.gnu.emacs-sA5EyHrnEIJjLrGbFnYFZQ==/lib/arm64/libemacs.so(+0x0) [0x7ba146d624]
08-22 07:42:57.960 16554 16599 I android_run_debug_thread: /data/app/~~GwLIc-L9KJZNDVGvtbZXQw==/org.gnu.emacs-sA5EyHrnEIJjLrGbFnYFZQ==/lib/arm64/libemacs.so(+0x0) [0x7ba143852c]
08-22 07:42:57.960 16554 16599 I android_run_debug_thread: /data/app/~~GwLIc-L9KJZNDVGvtbZXQw==/org.gnu.emacs-sA5EyHrnEIJjLrGbFnYFZQ==/lib/arm64/libemacs.so(+0x0) [0x7ba146f150]

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]

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

> I now ran
>   adb logcat -d | grep ...
> and got the enclosed log lines, which seems to be from today, not from
> the time of my bug report.
> But it is for emacs.

Thanks, this will be fixed shortly.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Johan Widén <j.e.widen@gmail.com> writes:
>
>> I now ran
>>   adb logcat -d | grep ...
>> and got the enclosed log lines, which seems to be from today, not from
>> the time of my bug report.
>> But it is for emacs.
>
> Thanks, this will be fixed shortly.

Was this fixed?  Is there anything left to do here, or should this be
closed?

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

[Johan Widén]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

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

On Sat, Sep 2, 2023, 18:30 Stefan Kangas <stefankangas@gmail.com> wrote:

> Po Lu <luangruo@yahoo.com> writes:
>
> > Johan Widén <j.e.widen@gmail.com> writes:
> >
> >> I now ran
> >>   adb logcat -d | grep ...
> >> and got the enclosed log lines, which seems to be from today, not from
> >> the time of my bug report.
> >> But it is for emacs.
> >
> > Thanks, this will be fixed shortly.
>
> Was this fixed?  Is there anything left to do here, or should this be
> closed?
>

[-- Attachment #2: Type: text/html, Size: 1046 bytes --]

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

[Stefan Kangas]

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

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

Thanks, I'm therefore closing this bug.

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

[Johan Widén]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

Glad to hear it!

On Sat, Sep 2, 2023, 20:52 Stefan Kangas <stefankangas@gmail.com> wrote:

> Johan Widén <j.e.widen@gmail.com> writes:
>
> > Yes, it seems to be fixed. I can no longer provoke the bug.
>
> Thanks, I'm therefore closing this bug.
>

[-- Attachment #2: Type: text/html, Size: 617 bytes --]