boost::iostreams::mapped_file_source::open causes exit code 3 on Windows but works in Ubuntu

Question

I'm using mapped_file_source from the boost::iostreams namespace to read from a large file in chunks:

boost::iostreams::mapped_file_source read_bytes(const char *file_path,
                                                unsigned long long int offset,
                                                unsigned long long int length) {
    iostreams::mapped_file_params parameters;
    parameters.path = file_path;
    parameters.length = static_cast<size_t>(length);
    parameters.flags = iostreams::mapped_file::mapmode::readonly;
    parameters.offset = static_cast<boost::iostreams::stream_offset>(offset);

    boost::iostreams::mapped_file_source file;

    file.open(parameters);

    if (file.is_open()) {
        return file;
    } else {
        printf("Failed to open file\n");
        exit(EXIT_FAILURE);
    }
}

My code works fine for Ubuntu in WSL (Windows Subsystem for Linux) but when I compile and run it on Windows, the 2nd file.open call causes the process to exit with exit code 3.

Reading file in 5 parts
Processing chunk 1/5
Processing chunk 2/5

Process finished with exit code 3

No error message or exception has been caused. The documentation suggests it to be ERROR_PATH_NOT_FOUND but that makes no sense.

I debugged both platform binaries and all variables are exactly identical with the only exceptions being the Unix style file path and the Windows style path as well as allocated addresses and system time variables so no memory corruption has occurred. I do not understand why this doesn't work on Windows when it should behave identically.

I'm using MinGW to compile for Windows and gcc 8.2 in Ubuntu.

"C:\Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin\x86_64-w64-mingw32-gcc.exe" --version
x86_64-w64-mingw32-gcc.exe (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If I read the file in a single go, it works fine (!). I'm aligning all offsets to page size multiples. The mapped_file_source is automatically closed when it falls out of scope so it's not a "file already open" issue (that would actually cause an exception by Boost).

Answer 1

Using MSVC the problem can no longer be reproduced now. In general, using Microsoft's compiler for Windows may be more reliable than the likes of MinGW, especially since I was using an "unofficial" toolchain.