Bug 104684 - lseek on /proc/*/maps fails
lseek on /proc/*/maps fails
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Rik van Riel
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-18 18:37 EDT by Ulrich Drepper
Modified: 2007-11-30 17:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-01 22:47:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2003-09-18 18:37:57 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030912
Firebird/0.6.1+ StumbleUpon/1.83

Description of problem:
Pick a process you have read access to /proc/PID/maps too which has at least one
occurrence of two anonymous memory lines following each other.  I.e., the no
file name in two or more consecutive lines.  Now compare


Version-Release number of selected component (if applicable):
kernel-hugemem-2.4.21-1.1931.2.432.ent

How reproducible:
Always

Steps to Reproduce:
0.Use bash as the shell
1.cat /proc/PID/maps
2.while read l; do echo $l; done < /proc/PID/maps
3.compare output
    

Actual Results:  These are two excerpts from the output of these program runs. 
First the cat output:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
00d3d000-00d3e000 rw-p 0000c000 08:02 1634087   
/home/drepper-local/glibc-build/20030916/nptl/libpthread.so
00d3e000-00d40000 rw-p 00000000 00:00 0
00d40000-00d41000 ---p 00000000 00:00 0
00d41000-01741000 rwxp 00001000 00:00 0
01741000-01742000 ---p 00a01000 00:00 0
01742000-02142000 rwxp 00a02000 00:00 0
02a9a000-02a9b000 ---p 00000000 00:00 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now the shell while loop:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
00d3d000-00d3e000 rw-p 0000c000 08:02 1634087
/home/drepper-local/glibc-build/20030916/nptl/libpthread.so
00d3e000-00d40000 rw-p 00000000 00:00 0
01741000-01742000 ---p 00a01000 00:00 0
02a9b000-0349b000 rwxp 00001000 00:00 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Expected Results:  Outputs should match.

Additional info:

This problem is also in the RHL9 kernel.  It seems fixed in the current 2.6 kernel.

When starting bash with

  strace -o OUT -s 20000 bash

and then running the while loop one can see that bash does something like this:

_llseek(0, 0, [57344], SEEK_CUR)        = 0
read(0, "00d3e000-00d40000 rw-p 00000000 00:00 0\n00d40000-00d41000 ---p
00000000 00:00 0\n00d41000-01741000 rwxp 00001000 00:00 0\n01741000", 128) = 128
_llseek(0, -88, [69552], SEEK_CUR)      = 0
write(1, "00d3e000-00d40000 rw-p 00000000 00:00 0\n", 40) = 40
ioctl(0, SNDCTL_TMR_TIMEBASE, 0xfeef0c90) = -1 ENOTTY (Inappropriate ioctl for
device)
_llseek(0, 0, [69552], SEEK_CUR)        = 0
read(0, "01741000-01742000 ---p 00a01000 00:00 0\n01742000-02142000 rwxp
00a02000 00:00 0\n02a9a000-02a9b000 ---p 00000000 00:00 0\n02a9b000", 128) = 128


The _llseek syscalls seem to work for file-backed mappings, but not for
anonymous memory.  This is probably a coincident, since in case the filename is
missing more lines fit into the 128 bytes one read() call gets from the kernel.
Comment 1 Ulrich Drepper 2003-09-18 18:39:10 EDT
Ugh.  It's a kernel problem but I first thought it's a bash problem and I
already filled in that field.  Reassign to kernel group.
Comment 2 Rik van Riel 2003-10-01 22:47:12 EDT
While the bug is certainly there, I see no reason to deviate from upstream 2.4
in this behaviour.  The 2.6 kernel does things as expected.

Note You need to log in before you can comment on or make changes to this bug.