Bug 70538 - r/w incompatibility between glibc-2.2.90 and 2.2.5
Summary: r/w incompatibility between glibc-2.2.90 and 2.2.5
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: glibc   
(Show other bugs)
Version: limbo
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
Blocks: 67218
TreeView+ depends on / blocked
Reported: 2002-08-02 12:26 UTC by Olivier Baudron
Modified: 2016-11-24 14:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-10 11:47:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
testcase in C (58 lines) (1.20 KB, text/plain)
2002-08-02 12:28 UTC, Olivier Baudron
no flags Details

Description Olivier Baudron 2002-08-02 12:26:30 UTC
The following testcase shows a r/w incompatibility between glibc-2.2.5-37
(updated rh7.3) and glibc-2.2.90-17 (beta limbo). Steps are:

1. fopen() file in "r" mode
2. append data to this file:
   2.a: fopen() file in "a" mode
   2.b: fprintf() on file
   2.c: fclose() file
3. fseek() to old end of file.
4. fgets()

With glibc-2.2.5-37: appended data are correctly read in step 4.

baud:~/Bug$ echo "Hello" >/tmp/foo
baud:~/Bug$ gcc -Wall -o test test.c
baud:~/Bug$ ./test

With glibc-2.2.90-17: no data can be read in step 4.

baud:~/Bug$ echo "Hello" >/tmp/foo
baud:~/Bug$ gcc -Wall -o test test.c
baud:~/Bug$ ./test
Error: fgets() 0: Success
Could not read appended data.

I don't know what the libc standard requires for this testcase.
Could you tell me if this is a bug or only an incompatibility?
In the case it is not a bug, then mutt should be fixed, because this is what
causes problems when checking new mails appended by sendmail to a 'mbox'

Comment 1 Olivier Baudron 2002-08-02 12:28:55 UTC
Created attachment 68444 [details]
testcase in C (58 lines)

Comment 2 Jakub Jelinek 2002-08-02 12:33:01 UTC
Yes, I know about this very well. The above testcase really is triggering
undefined behaviour, but from what I saw on mutt it does what is required,
ie. an fflush call in between. Roland just checked in a fix for this,
I'll give it some testing later today.

Comment 3 Olivier Baudron 2002-08-02 13:14:43 UTC
fflush() does not help...
I changed my testcase as shown below and I still have the same error in fgets().

--- test.c      2002-08-02 15:05:01 +0200
+++ test.c      2002-08-02 15:00:30 +0200
@@ -44,6 +44,9 @@
     /* Try to read appended data */
+    rc = fflush (fp);
+    check_rc (rc != 0, "fflush()");
     rc = fseek (fp, end, SEEK_SET);
     check_rc (rc != 0, "fseek()");

Comment 4 Jakub Jelinek 2002-08-02 13:18:44 UTC
Well, from a standards point of view it matters. That glibc until now did not
do this properly for mmap stdio is a bug.

Comment 5 Olivier Baudron 2002-08-02 17:32:13 UTC
Obviously, fragments of the file are mapped all over the place ;)
In the present state, it cannot work.

open("/tmp/foo", O_RDONLY)              = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
mmap2(NULL, 6, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40013000
      ^^^^^^^                                  ^^^^^^^^^^
stat64("/tmp/foo", {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
open("/tmp/foo", O_WRONLY|O_APPEND|O_CREAT, 0666) = 4
fstat64(4, {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
fstat64(4, {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
_llseek(4, 6, [6], SEEK_SET)            = 0
write(4, "...appended data...\n", 20)   = 20
close(4)                                = 0
munmap(0x40014000, 4096)                = 0

Comment 6 Olivier Baudron 2002-08-02 22:39:59 UTC
From libc/libio/bug-mmap-fflush.c (Roland McGrath 07/31):

if (strncmp (buffer, "From ", 5) != 0)
    abort ();

At least, now I am sure... I am not the only one to have mailbox problems ;)
And yes, this is stol^H^H^H^Hborrowed from mutt! ;)

Comment 7 Olivier Baudron 2002-08-10 11:47:51 UTC
Current glibc cvs works for me. Hope this will be backport soon to rawhide.

Comment 8 Olivier Baudron 2002-08-15 13:46:04 UTC
Fixed in -21. Thanks.

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