Re: Program crashes on stable/13 (but not on 12.3)
- In reply to: Peter : "Re: Program crashes on stable/13 (but not on 12.3)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.