Bug 104684
| Summary: | lseek on /proc/*/maps fails | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Ulrich Drepper <drepper> |
| Component: | kernel | Assignee: | Rik van Riel <riel> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-10-02 02:47:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. |
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.