GNU bug report logs - #75569
30.0.93; Large /proc/* file are read incompletely

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, Paul Eggert <eggert <at> cs.ucla.edu>, 75569 <at> debbugs.gnu.org
Subject: bug#75569: 30.0.93; Large /proc/* file are read incompletely
Date: Wed, 15 Jan 2025 19:08:03 +0200

>> > When opening a large file in /proc/* like /proc/cpuinfo in Emacs via
>> > find-file, the buffer content is incomplete, when comparing the output
>> > to the output produced by /bin/cat. The Eshell command eshell/cat has
>> > the same problem.The proc file system doesn't report file sizes since
>> > the files are dynamically generated. ls -l /proc/cpuinfo reports size 0.
>> > Emacs doesn't handle this well, limiting its reads to 16KiB.
>> >
>> > In Eshell:
>> >
>> > cat /proc/cpuinfo > #<buffer bug>  ==> truncated buffer (exactly 16KiB)
>> > *cat /proc/cpuinfo > #<buffer bug> ==> complete buffer (larger than 16KiB)
>> 
>> Strange, bug#9800 was closed as fixed, but I confirm the buffer is still
>> truncated.
>
> It was closed because it was fixed back then.

I'm sure I tested it when it was closed, so it was fixed back then indeed.

> But maybe commits 8650b3308dd and/or 3fb2c174d3a7 broke that later?

I confirm that reverting 8650b3308dd fixes it again after removing 'seekable'.

> The /proc/cpuinfo file on the system to which I have access is smaller
> than 16KB, so could someone who can access a larger cpuinfo file
> please see if those commits broke the fix, or maybe bisect?

To be able to test it you need at least 16 cpu cores.  If this is
not feasible, a simpler way would be just to try on another file
such as /proc/crypto.

Previous Next

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