Re: Program crashes on stable/13 (but not on 12.3)

From: Mark Johnston <markj_at_freebsd.org>
Date: Sun, 06 Mar 2022 15:59:12 UTC
On Sun, Mar 06, 2022 at 01:20:37AM +0100, Peter wrote:
> On Sun, Mar 06, 2022 at 04:26:10AM +0700, Eugene Grosbein wrote:
> ! 06.03.2022 2:26, Peter wrote:
> ! 
> ! Adding kib@ to CC: in case this is connected to recent commit by him.
> 
> It is.
>  
> ! > Hija,
> ! > 
> ! >  this program crashes SEGV on stable/13 after 135962 iterations,
> ! > but continues to run on 12.3.
> ! > 
> ! > My stable/13 is still at 22ba2970766 - if You happen to be on a
> ! > newer level, then please just try this out.
> ! > 
> ! > ------------------------------------------------------
> ! > #include <unistd.h>
> ! > #include <fcntl.h>
> ! > #include <stdio.h>
> ! > 
> ! > main() {
> ! >     char buf[] = "12345678901234567890123456789012345678901234567890";
> ! >     int fd = open("/dev/null", O_RDONLY);
> ! >     int i = 0;
> ! > 
> ! >     close(1);
> ! >     dup2(fd, 1);
> ! >     close(fd);
> ! > 
> ! >     while(1) {
> ! >       fputs(buf, stdout);
> ! >       fflush(stdout);
> ! >       i++;
> ! >       fprintf(stderr, "%d\n", i);
> ! >     }
> ! > }
> ! > ------------------------------------------------------
> ! > 
> ! > I know that the code is bogus, but this is exactly what one of our
> ! > ports does (and why it started to crash after upgrading to stable/13).
> ! > 
> ! > And I think it should not SEGV, anyway.
> ! > 
> ! > For the full story, read here:
> ! > 
> ! > https://forums.freebsd.org/threads/random-program-crashes-no-coredumps-and-error-94.84285/
> ! 
> ! fflush() in our libc recently got some change due to very old PR
> ! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=76398
> ! 
> ! That change was merged to stable/13 after 13.0-RELEASE:
> ! https://cgit.freebsd.org/src/commit/?id=afa9a1f5ec9974793a8744c55036ef5c4d08903d
> 
> Yes, this is the cause, I now checked before and after. I don't really
> see why it does what it does, even less why it only happens after so
> many invocations.
> 
> I wouldn't bother much about it, because such crappy code somehow
> deserves to crash - but then, concerned is sysutils/bareos-client
> backup tool, and arbitrary memory corruption appears there, and I
> am not sure if this could lead to silently corrupted backup data.
> So it's probably not the best idea to keep this into 13.1.

This should be fixed by a recent commit to the main branch, and it'll
make it into 13.1.