Re: Assertion error when building in Debug mode with MSVC

[Eric Blake]

[adding bug-gnulib]

On Mon, Jan 24, 2022 at 05:00:01PM +0100, Julien Marrec wrote:
> Hello,
> 
> I realize this is probably not a combination of platform, compiler and
> build type that you anticipated. m4 is used in a conan - the C++ package
> manager - recipe, and it serves as the basis for many other recipes (such
> as bison).
> 
> We encountered an issue when building it with Visual Studio (2019 for eg)
> in *Debug* mode (runtime MDd). At runtime, even `m4.exe --version` will
> throw the following assertion in ucrt.dll
> 
> ```
> minkernel\crts\ucrt\src\appcrt\lowio\close.cpp(49) : Assertion failed:
> (_osfile(fh) & FOPEN)
> ```
> 
> It seems that there is a double close happening, apparently from something
> gnulib overrides, as this small example produces exactly the same error:
> 
> ```
> 
> #include <io.h>
> #include <stdio.h>int main() {
>     int no =  _fileno (stdin);
>     _close(no);
>     fclose(stdin);
> }
> 
> ```

fclose() asserting because the underlying fd has been previously
closed seems odd; is it something that gnulib should work around by
overriding fclose() to be guaranteed that it has an open fd?

This may be fallout from the gnulib module closeout (and the function
close_stdout), trying hard to ensure that any write failures to stdout
are properly detected.  That may be the spot where we would add a
workaround to your platform's assertion failure in fclose().

> 
> An issue can be found there:
> https://github.com/conan-io/conan-center-index/issues/8920
> An older discussion with more information is here:
> https://github.com/conan-io/conan-center-index/pull/7369#issuecomment-927159346
> 
> I have implemented a poor-man's workaround for the time being which
> consists in calling _CrtSetReportMode early in the main function of m4.c so
> that the popup isn't triggered and instead it prints to the console, but I
> would ideally like to see if there isn't a small patch we could do to avoid
> the double close to begin with.
> 
> Could you help please?
> 
> Thank you for your time and contributions!
> Best,
> Julien
> --
> Julien Marrec, EBCP, BPI MFBA
> Owner at EffiBEM <http://www.effibem.com>
> T: +33 6 95 14 42 13
> 
> LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr
> <https://fr.linkedin.com/in/julienmarrec/fr>) :
> <http://www.linkedin.com/in/julienmarrec>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org