[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: GNU bug Tracking System
Subject: bug#9800: closed (Incomplete truncated file buffers from the /proc filesystem)
Date: Mon, 13 Feb 2023 20:48:01 +0000

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

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 
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:
4 files contained unexpected results:

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

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

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

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

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

--- End Message ---

reply via email to

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