GNU bug report logs - #47596
File descriptor error when exiting emacs on android 11

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47596 in the body.
You can then email your comments to 47596 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: bug-gnu-emacs <at> gnu.org
Subject: File descriptor error when exiting emacs on android 11
Date: Sun, 04 Apr 2021 21:20:35 +0200

Hi,

Android 10 introduced a new "file descriptor sanitizer" (fdsan, see [1]
for docs) which detects issues when opening and closing files across
multiple threads. On android 10 warnings were given, while on android
11 programs are killed instantly if issues are detected. 

Starting and then exiting emacs, or simply just running for example
`emacs --version`, gives an error. `gdb --args emacs --version` gives
this backtrace:

```
Starting program: /data/data/com.termux/files/usr/bin/emacs --version
GNU Emacs 27.2
Copyright (C) 2021 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
fdsan: attempted to close file descriptor 2, expected to be unowned,
actually owned by FILE* 0xb6c8800c

Program received signal SIGABRT, Aborted.
0xb63789e8 in fdsan_error(char const*, ...) ()
   from /apex/com.android.runtime/lib/bionic/libc.so
(gdb) bt full
#0  0xb63789e8 in fdsan_error(char const*, ...) ()
   from /apex/com.android.runtime/lib/bionic/libc.so
No symbol table info available.
#1  0xb63786fe in android_fdsan_close_with_tag ()
   from /apex/com.android.runtime/lib/bionic/libc.so
No symbol table info available.
#2  0xb63b83c0 in __sclose () from
/apex/com.android.runtime/lib/bionic/libc.so
No symbol table info available.
#3  0xb63b8f24 in __FILE_close(__sFILE*) ()
   from /apex/com.android.runtime/lib/bionic/libc.so
No symbol table info available.
#4  0x7f7e6a76 in close_stream (stream=0xb63cde44 <__sF+168>)
    at /home/builder/.termux-build/emacs/src/lib/close-stream.c:61
        some_pending = false
        prev_fail = false
        fclose_fail = 243
#5  0x7f68a872 in close_output_streams ()
    at /home/builder/.termux-build/emacs/src/src/sysdep.c:2840
        err = false
#6  0xb63c10d6 in __cxa_finalize ()
   from /apex/com.android.runtime/lib/bionic/libc.so
No symbol table info available.
#7  0xb63bc7b8 in exit () from
/apex/com.android.runtime/lib/bionic/libc.so
No symbol table info available.
#8  0x7f655d92 in main (argc=2, argv=0xbefff504)
    at /home/builder/.termux-build/emacs/src/src/emacs.c:1132
        version = 0xb5e68133 "27.2"
        copyright = 0xb5e68138 "Copyright (C) 2021 Free Software
Foundation, Inc."
        stack_bottom_variable = 0x7f655a61 <main>
        do_initial_setlocale = false
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        dump_mode = 0x0
        skip_args = 1
        temacs = 0x0
        attempt_load_pdump = true
        sockfd = -1225460908
        module_assertions = 244
```

The emacs here was a debug build from the 27.2 tag, configured with:


 'configure --disable-dependency-tracking
 --prefix=/data/data/com.termux/files/usr
 --libdir=/data/data/com.termux/files/usr/lib
 --sbindir=/data/data/com.termux/files/usr/bin --disable-rpath
 --disable-rpath-hack --host=arm-linux-androideabi --disable-autodepend
 --with-gif=no --with-gnutls --with-jpeg=no --without-gconf
 --without-gsettings --without-lcms2 --without-x --with-png=no
 --with-tiff=no --with-xml2 --with-xpm=no --without-dbus
 --without-selinux --with-modules --with-pdumper=yes --with-
dumping=none
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 emacs_cv_sanitize_address=yes emacs_cv_prog_cc_no_pie=no
 ac_cv_lib_elf_elf_begin=no gl_cv_func_dup2_works=no
 ac_cv_func_setrlimit=no emacs_cv_func__setjmp=no
 emacs_cv_func_sigsetjmp=no --disable-nls --enable-shared
 --enable-static --libexecdir=/data/data/com.termux/files/usr/libexec
 'CFLAGS= -march=armv7-a -mfpu=neon -mfloat-abi=softfp -mthumb
 -fstack-protector-strong -g3 -O0 -Wall -gdwarf-4' 'CPPFLAGS=
 -D_FORTIFY_SOURCE=2 -D__USE_FORTIFY_LEVEL=2
 -I/data/data/com.termux/files/usr/include'
 'LDFLAGS=-L/data/data/com.termux/files/usr/lib
 -Wl,-rpath=/data/data/com.termux/files/usr/lib -march=armv7-a -fopenmp
 -static-openmp -Wl,--enable-new-dtags -Wl,--as-needed
 -Wl,-z,relro,-z,now''

Debugging these issues are very tedious in my experience so far
(probably easier for actual android apps). I will try to boil down the
relevant emacs code into a smaller program that still reproduces the
error.

Based on the backtrace it seem to be how stderr is opened (and closed)
that is problematic somehow.

Please let me know if you have any insights, or if I can provide
additional useful information.

Best regards,
Henrik Grimler

[1]
https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md

Message #8 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Henrik Grimler <henrik <at> grimler.se>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Sun, 04 Apr 2021 22:31:21 +0300

> From: Henrik Grimler <henrik <at> grimler.se>
> Date: Sun, 04 Apr 2021 21:20:35 +0200
> 
> Debugging these issues are very tedious in my experience so far
> (probably easier for actual android apps). I will try to boil down the
> relevant emacs code into a smaller program that still reproduces the
> error.

Yes, please.

> Based on the backtrace it seem to be how stderr is opened (and closed)
> that is problematic somehow.

Any idea what was "the other thread" involved in this situation?
Emacs is generally a single-threaded program.

Message #11 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Sun, 04 Apr 2021 22:11:24 +0200

Hi,

> > Based on the backtrace it seem to be how stderr is opened (and
> > closed)
> > that is problematic somehow.
> 
> Any idea what was "the other thread" involved in this situation?
> Emacs is generally a single-threaded program.

I do not know unfortunately. I am not entirely certain the sanitizer is
trustworthy yet (but since it is active per default now I suppose it
should have been tested extensively). 

Tests so far show that optimisation level, and compiler, can influence
if these error occur or not, but for emacs it happens with -O0 as well
with clang-11. I opened an issue on the android issue tracker about the
fd sanitizer after investigating a fdsan error for texlive, since I do
not understand what the issue in the minimal example there is. We will
see what they say about it:
https://issuetracker.google.com/issues/184380442

Best regards,
Henrik Grimler

Message #14 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 10:14:10 +0200

Hi,

Compiling this, on any optimisation level, is enough to trigger the
error:

```
#include <stdio.h>
int main()
{
  fdopen (2, "w");
  fclose (stderr);
}
```

In emacs fdopen is run in init_standard_fds, where we have

```
[...]

  force_open (STDERR_FILENO, O_RDONLY);

  /* Set buferr if possible on platforms defining _PC_PIPE_BUF, as
     they support the notion of atomic writes to pipes.  */
  #ifdef _PC_PIPE_BUF
    buferr = fdopen (STDERR_FILENO, "w");
    if (buferr)
      setvbuf (buferr, NULL, _IOLBF, 0);
  #endif
}
```

so I suppose there is either some very fundamental issue with 
`fdopen (STDERR_FILENO, "w")` here, or the file descriptor sanitizer on
android is broken.

If I avoid that part of init_standard_fds, i.e. change the ifdef to
something like `#if defined(_PC_PIPE_BUF) && !defined(__ANDROID__)`, I
get an emacs that seem to fully work on android.

Best regards,
Henrik Grimler

Message #17 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 10:59:55 +0200

Hi again,


> Compiling this, on any optimisation level, is enough to trigger the
> error:
> 
> ```
> #include <stdio.h>
> int main()
> {
>   fdopen (2, "w");
>   fclose (stderr);
> }
> ```

Changing to this:

```

#include <stdio.h>
int main()
{
  FILE *err = fdopen (2, "w");
  fclose (err);
}
```

makes it work. So I suppose the sanitizer does not like that stderr is
closed with `fclose (stderr)` instead of by using the fd obtained from
fdopen (which was thrown away in my minimal example). 

Still not sure if this is actually problematic, but at least now I
understand how the sanitizer "thinks".

Best regards,
Henrik Grimler

Message #20 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 11:48:50 +0200

Hi,

A better way to fix the error is to use buferr instead of stderr when
calling `close_streams` in `close_output_streams`. I cannot see any
obvious problems with this, so I propose this patch:

```

--- ./src/sysdep.c.orig	2021-04-05 09:06:33.847835653 +0000
+++ ./src/sysdep.c	2021-04-05 09:05:47.957856162 +0000
@@ -2837,8 +2837,8 @@
      sanitizer might report to stderr after this function is invoked.
*/
   bool err = buferr && (fflush (buferr) != 0 || ferror (buferr));
   if (err | (ADDRESS_SANITIZER
-	     ? fflush (stderr) != 0 || ferror (stderr)
-	     : close_stream (stderr) != 0))
+	     ? fflush (buferr) != 0 || ferror (buferr)
+	     : close_stream (buferr) != 0))
     _exit (EXIT_FAILURE);
 }
 ^L
```

With it I can start and exit emacs on android without the fdsan error. 

Best regards,
Henrik Grimler

Message #23 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Henrik Grimler <henrik <at> grimler.se>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 15:50:48 +0300

> From: Henrik Grimler <henrik <at> grimler.se>
> Cc: 47596 <at> debbugs.gnu.org
> Date: Mon, 05 Apr 2021 10:14:10 +0200
> 
> Compiling this, on any optimisation level, is enough to trigger the
> error:
> 
> ```
> #include <stdio.h>
> int main()
> {
>   fdopen (2, "w");
>   fclose (stderr);
> }
> ```

Any idea why?  It makes no sense to me, and the above is an entirely
valid program, AFAICT.

> In emacs fdopen is run in init_standard_fds, where we have
> 
> ```
> [...]
> 
>   force_open (STDERR_FILENO, O_RDONLY);
> 
>   /* Set buferr if possible on platforms defining _PC_PIPE_BUF, as
>      they support the notion of atomic writes to pipes.  */
>   #ifdef _PC_PIPE_BUF
>     buferr = fdopen (STDERR_FILENO, "w");
>     if (buferr)
>       setvbuf (buferr, NULL, _IOLBF, 0);
>   #endif
> }
> ```

This just creates a copy of stderr that has special buffering.  Again,
entirely valid for a C program to do that.

> so I suppose there is either some very fundamental issue with 
> `fdopen (STDERR_FILENO, "w")` here, or the file descriptor sanitizer on
> android is broken.

Likely the latter, so I'm reluctant to make any changes in Emacs until
the issue you opened against Android gets some response that makes
sense.

> If I avoid that part of init_standard_fds, i.e. change the ifdef to
> something like `#if defined(_PC_PIPE_BUF) && !defined(__ANDROID__)`, I
> get an emacs that seem to fully work on android.

Feel free to make such changes in your copy, but I'd prefer not to
change Emacs until the root cause behind these weird problems becomes
clear.

Message #26 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Henrik Grimler <henrik <at> grimler.se>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 15:52:22 +0300

> From: Henrik Grimler <henrik <at> grimler.se>
> Cc: 47596 <at> debbugs.gnu.org
> Date: Mon, 05 Apr 2021 10:59:55 +0200
> 
> > #include <stdio.h>
> > int main()
> > {
> >   fdopen (2, "w");
> >   fclose (stderr);
> > }
> > ```
> 
> Changing to this:
> 
> ```
> 
> #include <stdio.h>
> int main()
> {
>   FILE *err = fdopen (2, "w");
>   fclose (err);
> }
> ```
> 
> makes it work.

Which again makes no sense, because the program that works is a no-op:
it creates a copy of stderr and immediately closes it.

> So I suppose the sanitizer does not like that stderr is
> closed with `fclose (stderr)` instead of by using the fd obtained from
> fdopen (which was thrown away in my minimal example). 
> 
> Still not sure if this is actually problematic, but at least now I
> understand how the sanitizer "thinks".

If that's what it thinks, it's a clear bug in the sanitizer, IMO.

Message #29 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Henrik Grimler <henrik <at> grimler.se>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 15:57:45 +0300

> From: Henrik Grimler <henrik <at> grimler.se>
> Cc: 47596 <at> debbugs.gnu.org
> Date: Mon, 05 Apr 2021 11:48:50 +0200
> 
> A better way to fix the error is to use buferr instead of stderr when
> calling `close_streams` in `close_output_streams`. I cannot see any
> obvious problems with this, so I propose this patch:

You are operating on the wrong stream, so I do see a problem with this
patch.  The purpose of this fragment is to close stderr, not the
buffered copy of stderr.

> --- ./src/sysdep.c.orig	2021-04-05 09:06:33.847835653 +0000
> +++ ./src/sysdep.c	2021-04-05 09:05:47.957856162 +0000
> @@ -2837,8 +2837,8 @@
>       sanitizer might report to stderr after this function is invoked.
> */
>    bool err = buferr && (fflush (buferr) != 0 || ferror (buferr));
>    if (err | (ADDRESS_SANITIZER
> -	     ? fflush (stderr) != 0 || ferror (stderr)
> -	     : close_stream (stderr) != 0))
> +	     ? fflush (buferr) != 0 || ferror (buferr)
> +	     : close_stream (buferr) != 0))
>      _exit (EXIT_FAILURE);
>  }
>  ^L
> ```
> 
> With it I can start and exit emacs on android without the fdsan error. 

Is ADDRESS_SANITIZER defined in your build?

In any case, I do want to wait for the Android developers to respond
to the issue in their tracker.

Thanks.

Message #32 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 15:38:36 +0200

Hi,

> You are operating on the wrong stream, so I do see a problem with this
> patch.  The purpose of this fragment is to close stderr, not the
> buffered copy of stderr.

> 
Thanks for the feedback!

> Is ADDRESS_SANITIZER defined in your build?

Yes, it is configured with emacs_cv_sanitize_address=yes. Setting this
option has been done for android since emacs 25, and supposedly fixed
some malloc issue back then [1]. I tried building without setting
emacs_cv_sanitize_address=yes just now (configure then sets =no), but
it does not seem to influence this fdsan error.

> In any case, I do want to wait for the Android developers to respond
> to the issue in their tracker.

I will update the issue and add the minimal non-working example
obtained here as well.

Best regards,
Henrik Grimler

[1]
https://github.com/termux/termux-packages/commit/8ce98d7fe9130cd151cc2ec34b3b1e7ecb0aeace#diff-8fd6b84ed67057870fa4f209d2309b53bf3c097b732cb3b8e639f58a37d138c1R7

Message #35 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 05 Apr 2021 19:29:52 +0200

Hi,

I received feedback on the android issue tracker 
https://issuetracker.google.com/issues/184380442 
that the snippet:

> > #include <stdio.h>
> > int main()
> > {
> >   fdopen (2, "w");
> >   fclose (stderr);
> > }

is problematic, because:

> yes. you have two FILE*s that both think they own file descriptor 2.
> depending on what you're actually trying to do, you probably meant to
> use freopen(3) instead?
https://man7.org/linux/man-pages/man3/fopen.3.html

Does freopen make sense for buferr?

> > In emacs fdopen is run in init_standard_fds, where we have
> > 
> >   force_open (STDERR_FILENO, O_RDONLY);
> > 
> >   /* Set buferr if possible on platforms defining _PC_PIPE_BUF, as
> >      they support the notion of atomic writes to pipes.  */
> >   #ifdef _PC_PIPE_BUF
> >     buferr = fdopen (STDERR_FILENO, "w");
> >     if (buferr)
> >       setvbuf (buferr, NULL, _IOLBF, 0);
> >   #endif
> > }
> 
> This just creates a copy of stderr that has special buffering. 
> Again,
> entirely valid for a C program to do that.

I probably should have included a bit more context in the android bug
report to better show what the code does. 

Best regards,
Henrik Grimler

Message #38 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Henrik Grimler <henrik <at> grimler.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Thu, 06 May 2021 12:45:17 +0200

Henrik Grimler <henrik <at> grimler.se> writes:

>> > In emacs fdopen is run in init_standard_fds, where we have
>> > 
>> >   force_open (STDERR_FILENO, O_RDONLY);
>> > 
>> >   /* Set buferr if possible on platforms defining _PC_PIPE_BUF, as
>> >      they support the notion of atomic writes to pipes.  */
>> >   #ifdef _PC_PIPE_BUF
>> >     buferr = fdopen (STDERR_FILENO, "w");
>> >     if (buferr)
>> >       setvbuf (buferr, NULL, _IOLBF, 0);
>> >   #endif
>> > }
>> 
>> This just creates a copy of stderr that has special buffering. 
>> Again,
>> entirely valid for a C program to do that.
>
> I probably should have included a bit more context in the android bug
> report to better show what the code does. 

Did you try to include this context in the Android bug report and see
what they say then?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #41 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Mon, 10 May 2021 09:23:05 +0200

Hi Lars,

On Thu, 2021-05-06 at 12:45 +0200, Lars Ingebrigtsen wrote:
> > I probably should have included a bit more context in the android bug
> > report to better show what the code does. 
> 
> Did you try to include this context in the Android bug report and see
> what they say then?
> 

I added another comment now with a slightly more verbose example: 

```
#include <stdlib.h>
#include <unistd.h>

/* If FD is not already open, arrange for it to be open with FLAGS.  */
static void
force_open (int fd, int flags)
{
  if (dup2 (fd, fd) < 0)
    {
      int n = open ("/dev/null", flags);
      if (n < 0 || (fd != n && (dup2 (n, fd) < 0 || close (n) == 0 !=
0)))
	exit (EXIT_FAILURE);
    }
}

/* A stream that is like stderr, except line buffered.  It is NULL
   during startup, or if line buffering is not in use.  */
static FILE *buferr;

int
main()
{
  /* Make sure stderr are open to something, so that the file
   descriptor is not hijacked by later system calls.  */
  force_open (STDERR_FILENO, O_RDONLY);

  /* Set buferr if possible on platforms defining _PC_PIPE_BUF, as
     they support the notion of atomic writes to pipes.  */
  #ifdef _PC_PIPE_BUF
    buferr = fdopen (STDERR_FILENO, "w");
    if (buferr)
      setvbuf (buferr, NULL, _IOLBF, 0);
  #endif

  int err = buferr && (fflush (buferr) != 0 || ferror (buferr));
  if (err | (fclose (stderr) != 0))
    return 1;
  return 0;
}
```

Hopefully they have time to provide some feedback.

Best regards,
Henrik Grimler

Message #44 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, eliz <at> gnu.org
Cc: 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Tue, 11 May 2021 19:06:11 +0200

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

Hi again,

Enh at google suggested [1] that `setlinebuf (stderr)` could be an
alternative instead of opening a copy of stderr.  I tried out the
attached patch, which removes the buferr variable and uses setlinebuf
on stderr instead, and it seem to work (in the sense that emacs opens
and closes without errors) on archlinux as well as android. 

Could this work or do we need to have both buferr and stderr?

Best regards,
Henrik Grimler

[1] https://issuetracker.google.com/issues/184380442

[line_buffered_stderr.patch (text/x-patch, attachment)]

Message #47 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Henrik Grimler <henrik <at> grimler.se>
Cc: eliz <at> gnu.org, 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Wed, 12 May 2021 15:52:52 +0200

Henrik Grimler <henrik <at> grimler.se> writes:

> Enh at google suggested [1] that `setlinebuf (stderr)` could be an
> alternative instead of opening a copy of stderr.  I tried out the
> attached patch, which removes the buferr variable and uses setlinebuf
> on stderr instead, and it seem to work (in the sense that emacs opens
> and closes without errors) on archlinux as well as android. 
>
> Could this work or do we need to have both buferr and stderr?

Makes sense to me, but I seem to vaguely recall there being a lot of
discussion about the buffered stderr when it was introduced...  but none
of the details.  Eli?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #50 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47596 <at> debbugs.gnu.org, henrik <at> grimler.se
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Wed, 12 May 2021 17:01:36 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eliz <at> gnu.org,  47596 <at> debbugs.gnu.org
> Date: Wed, 12 May 2021 15:52:52 +0200
> 
> Henrik Grimler <henrik <at> grimler.se> writes:
> 
> > Could this work or do we need to have both buferr and stderr?
> 
> Makes sense to me, but I seem to vaguely recall there being a lot of
> discussion about the buffered stderr when it was introduced...  but none
> of the details.  Eli?

We need them both, yes.  The second one was introduced for a reason,
so removing it would give us back the problems it solved.

setlinebuf is not portable enough, and line buffering isn't supported
on MS-Windows anyway.  Maybe we could make some archlinux specific
change, although that's ugly.

And I'm worried that we don't actually understand the nature of the
problem well enough: our code doesn't close both FILE streams, it
closes at most only one.  So this sounds to me like a false positive
of the sanitizer, not a real problem with our code...

Message #53 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: henrik <at> grimler.se, 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Wed, 29 Jun 2022 12:47:27 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> And I'm worried that we don't actually understand the nature of the
> problem well enough: our code doesn't close both FILE streams, it
> closes at most only one.  So this sounds to me like a false positive
> of the sanitizer, not a real problem with our code...

Henrik, is this still a problem with current versions of Emacs/Android?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #58 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <henrik <at> grimler.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Wed, 29 Jun 2022 15:25:58 +0200

Hi Lars,

On Wed, Jun 29, 2022 at 12:47:27PM +0200, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > And I'm worried that we don't actually understand the nature of the
> > problem well enough: our code doesn't close both FILE streams, it
> > closes at most only one.  So this sounds to me like a false positive
> > of the sanitizer, not a real problem with our code...
> 
> Henrik, is this still a problem with current versions of Emacs/Android?

The sanitizer still complains about it (just checked a new emacs build
from master branch), but we have at least figured out a way to disable
the sanitizer [1], so IMO the bug can be closed.

For the record ~10 different packages out of around 2000 has triggered
this file descriptor sanitizer (that I've seen so far), and in most
cases it has been as unclear as for emacs what the issue is/if there
actually is an issue.

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

[1] https://github.com/termux/termux-packages/blob/master/packages/emacs/disable-fdsan.patch

Best regards,
Henrik Grimler

Message #61 received at 47596 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Henrik Grimler <henrik <at> grimler.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47596 <at> debbugs.gnu.org
Subject: Re: bug#47596: File descriptor error when exiting emacs on android 11
Date: Thu, 30 Jun 2022 11:07:18 +0200

Henrik Grimler <henrik <at> grimler.se> writes:

> The sanitizer still complains about it (just checked a new emacs build
> from master branch), but we have at least figured out a way to disable
> the sanitizer [1], so IMO the bug can be closed.
>
> For the record ~10 different packages out of around 2000 has triggered
> this file descriptor sanitizer (that I've seen so far), and in most
> cases it has been as unclear as for emacs what the issue is/if there
> actually is an issue.

Ah, I see.  OK, I guess there's nothing to be done on the Emacs side
here, then, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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