Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #814874 > unrolled thread

Bug#858529: libc6: fgets repeats content after fork on stretch only

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#858529: libc6: fgets repeats content after fork on stretch only Neil Spring <nspring@cs.umd.edu> - 2017-03-23 05:20 +0100
    Bug#858529: libc6: fgets repeats content after fork on stretch only Florian Weimer <fw@deneb.enyo.de> - 2017-03-23 15:50 +0100

#814874 — Bug#858529: libc6: fgets repeats content after fork on stretch only

Package: libc6
Version: 2.24-9
Severity: normal

Dear Maintainers,

I'm testing a programming exercise for students, and found failed tests
that I believe are due to libc6.  I retried the minimal test case on
every machine I have access to, and found that only my two Debian Stretch
machines failed, then took a clean vagrant Jessie box, confirmed correct
behavior, updated to Stretch, and reproduced the error.

I expect the following code to print its input, once.  Instead, it 
prints lines two through four twice. (abcdbcd).

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main() {
  char buf[255];
  int ln=1;
  int status;
  FILE *f;

  f = fopen("/tmp/fourlines", "w");
  fprintf(f, "a\nb\nc\nd\n");
  fclose(f);

  f= fopen("/tmp/fourlines", "r");
  printf("%d: %s", ln++, fgets(buf, 255, f));

  if(fork() == 0) { exit(1); }
  wait(&status);

  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  exit(0);
}

Output on my two machines and vm with 2.24-9:

1: a
2: b
3: c
4: d
5: b
6: c
7: d

The behavior is consistent under the debugger; I don't see 
anything obvious in the FILE structure, and notice that a 
read occurs between the d and b (the end of input and when 
what should be old data is back in).

I plan to look into slightly older libc6 versions to find the 
regression, but that will take me some time.

This is sent from the virtual machine, to keep it as clean as 
possible.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:6.3.0-6

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.60
pn  glibc-doc              <none>
ii  libc-l10n              2.24-9
ii  locales                2.24-9

-- debconf information:
  glibc/restart-failed:
  glibc/kernel-too-old:
  glibc/upgrade: true
  glibc/restart-services:
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true

[toc] | [next] | [standalone]

#814956

tags 858529 upstream
forwarded 858529 https://sourceware.org/bugzilla/show_bug.cgi?id=20598
thanks

* Neil Spring:

>   if(fork() == 0) { exit(1); }

exit flushes the stdio buffers in the child.  Upstream concluded that
this leads to undefined behavior:

| Yes, this is about the exit actually.  But reading "2.5.1
| Interaction of File Descriptors and Standard I/O Streams", I think
| this is really undefined, because the required action is not
| performed before the call to fork, and the correct fix is to use
| _exit in the forked child.

<https://sourceware.org/bugzilla/show_bug.cgi?id=20598#c2>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web