bug#9800: closed (Incomplete truncated file buffers from the /proc filesystem)

[GNU bug Tracking System]

Your message dated Mon, 13 Feb 2023 12:47:33 -0800
with message-id <f711f43f-6892-f849-21ec-26376c351f11@cs.ucla.edu>
and subject line Re: bug#9800: Incomplete truncated file buffers from the /proc 
filesystem
has caused the debbugs.gnu.org bug report #9800,
regarding Incomplete truncated file buffers from the /proc filesystem
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
9800: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9800
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Incomplete truncated file buffers from the /proc filesystem
>
>
>
>
> Date: 
>
> Thu, 20 Oct 2011 01:59:42 +0300
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (x86_64-pc-linux-gnu)
>
>
>
>
> Large files from the /proc filesystem are visited incompletely,
> their file buffers are truncated at the position 65536.
> One possible test case to reproduce this is to load enough libraries
> with e.g. (imagemagick-register-types) and visit Emacs's maps file
> in /proc/$PID/maps.
>
> Andreas said in 
> http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00782.html
> that it's due to this code in `insert-file-contents':
>
>           /* The file size returned from stat may be zero, but data
>              may be readable nonetheless, for example when this is a
>              file in the /proc filesystem.  */
>           if (end_offset == 0)
>             end_offset = READ_BUF_SIZE;
>
> How this could be fixed?  Should it keep reading while more data can be
> read from the file?
>
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem Date: Mon, 13 Feb 2023 12:47:33 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

On 2023-02-12 02:21, Arsen Arsenović wrote:

... or such.  This approach is robust and general, and I suspect it'd
even work for named pipes.

Although indeed robust and general and it will work with named pipes in some cases, it still has a problem if the other side of the named pipe outputs data very slowly: Emacs will still seem to hang until you type C-g.

That being said, the approach is an improvement and it fixes the original bug report so I installed the attached and am boldly closing the bug report (we can reopen it if I'm wrong). The last patch in the attached series is the actual fix: the others are minor cleanups of this messy area, which I discovered while looking into the fix.

This patch does not address the abovementioned issue of named pipes, nor the issue of inserting very large files: the code should behave roughly the same as before in those two areas. These issues can be raised in separate bug reports if needed.

PS. I was surprised to see that Emacs master currently has several test case failures on GNU/Linux (specifically the latest Fedora and Ubuntu releases). I hope these are known and that people are working on them.

1 files did not finish:
  lisp/server-tests.log
4 files contained unexpected results:
  src/lread-tests.log
  lisp/international/mule-tests.log
  lisp/emacs-lisp/map-tests.log
  lisp/emacs-lisp/bytecomp-tests.log

0001-Improve-insert-file-contents-checking.patch
Description: Text Data

0002-Improve-insert-file-contents-on-non-regular-files.patch
Description: Text Data

0003-Don-t-scan-text-twice-to-guess-coding-system.patch
Description: Text Data

0004-Fix-src-fileio.c-comment.patch
Description: Text Data

0005-Fix-insert-file-contents-on-proc-files.patch
Description: Text Data

--- End Message ---