STXXL and Cygwin

  • ropar


    I am not sure, if Cygwin is supported actually, but I hope that someone still might be able to help me.

    Some colleagues of mine implemented some code using STXXL. It works perfectly on Ubuntu (both 1.3.0 and 1.3.1), but unfortunately not on cygwin.

    I get following error

    [STXXL-MSG] Caught exception: Error in function virtual void stxxl::ufs_file_base::set_size(stxxl::file::offset_type) Invalid argument

    after executing the following lines:

        stxxl::syscall_file f(file, stxxl::file::DIRECT | stxxl::file::RDWR);
        typedef stxxl::vector<sortedType> vector_type;
        vector_type v(&f);

    This error also occurs when running some of the test files of stxxl (e.g test_map(_random).stxxl.bin, test_vector.stxxl.bin).

    I am using Win7 64 Bit, uptodate Cygwin and tried it already on several machines (all Win7), gcc 4.5.3, non-parallel (without mcstl and boost).

    I would be glad for any idea,

  • The following piece of code should be able to trigger the error without needing a vector (you might need to adjust the "size", try multiples of 4 KB or 2 MB (2*1024*1024):

    stxxl::syscall_file f(file, stxxl::file::DIRECT | stxxl::file::RDWR);

    set_size() (in io/ufs_file_base.cpp) has calls to ftruncate and lseek - run your program in a debugger and find the one that fails - and what the arguments were that resulted in EINVAL.

    Have you tried without stxxl::file::DIRECT ?


  • ropar

    Thanks for your fast reply. The code snippet reproduces the problem, i.e. using just stxxl::file::DIRECT as option.

    GDB provides following output:

    [code[(gdb) run
    Starting program: /workspace/BinarySortMain
    New Thread 1256.0xf0c]

    terminate called after throwing an instance of 'stxxl::io_error'
      what():  Error in function virtual void stxxl::ufs_file_base::set_size(stxxl::file::offset_type) Bad file descriptor

    Program received signal SIGABRT, Aborted.
    0x00000000 in ?? ()
    (gdb) thread apply all where
    Thread 2 (Thread 1256.0xf24):
    #0  0x74f7b727 in RaiseException () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
    #1  0x74f8256b in OutputDebugStringA () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
    #2  0x40010006 in ?? ()
    #3  0x00000000 in ?? ()

    Thread 1 (Thread 1256.0xf0c):
    #0  0x00000000 in ?? ()
    #1  0x7728f8dd in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll
    #2  0x74f7d232 in WriteFile () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
    #3  0x0000009c in ?? ()
    #4  0x76d612ac in KERNEL32!BaseFlushAppcompatCache () from /cygdrive/c/Windows/syswow64/kernel32.dll
    #5  0x0000009c in ?? ()
    #6  0x610dbcc0 in sig_send(_pinfo*, siginfo_t&, _cygtls*) () from /usr/bin/cygwin1.dll
    #7  0x610d915e in _pinfo::kill(siginfo_t&) () from /usr/bin/cygwin1.dll
    #8  0x610d962e in kill0(int, siginfo_t&) () from /usr/bin/cygwin1.dll
    #9  0x610d9780 in kill () from /usr/bin/cygwin1.dll
    #10 0x610d97ac in raise () from /usr/bin/cygwin1.dll
    #11 0x610d9a85 in abort () from /usr/bin/cygwin1.dll
    #12 0x6fa9e945 in cygstdc++-6!_ZN9__gnu_cxx27__verbose_terminate_handlerEv () from /usr/bin/cygstdc++-6.dll
    #13 0x6fa98e49 in cygstdc++-6!_ZN10__cxxabiv111__terminateEPFvvE () from /usr/bin/cygstdc++-6.dll
    #14 0x6faedf53 in cygstdc++-6!_ZSt9terminatev () from /usr/bin/cygstdc++-6.dll
    #15 0x6faf3aef in cygstdc++-6!__cxa_throw () from /usr/bin/cygstdc++-6.dll
    #16 0x00409b6b in _fu1579___ZNSs4_Rep20_S_empty_rep_storageE ()
    #17 0x0040a896 in _fu1596___ZNSs4_Rep20_S_empty_rep_storageE ()
    #18 0x0040230d in main (argc=1, argv=0x28ac30) at BinarySortMain.cpp:354
            f = <incomplete type>

    thread apply all where full doesn't provide any more information.
    Actually I am not very experienced using gdb and I am not sure, if it's possible to get more helpful information, since I never needed more than the basics.

    It does not seem to be a "real" stxxl problem, but a problem of some method stxxl uses, which is not supported correctly by Cygwin.

    Do you think there might be any solution to the problem (besides avoiding stxxl::file::DIRECT) or does it just not work with Cygwin?

    Thanks for your help.

  • Well, stxxl::file::DIRECT (which maps to open's O_DIRECT) is certainly the first thing to break on a non-Unix OS, because it's low-level, and non-POSIX .  So there are good chances that the "rest" will work fine.  But somebody has to try and test that, e.g. by trying the included test programs with O_DIRECT.  We cannot guarantee that it works, though.  Apart from that, we have no clue about the potential performance implications…

    On the other hand, why don't you use it on Windows natively?  STXXL supports that. 


  • As Johannes already wrote, O_DIRECT may not be implemented properly in Cygwin.
    But DIRECT I/O support may also depend on the underlying filesystem (on Linux e.g. tmpfs and glusterfs don't support it, but so far nobody has made detailed tests on Windows systems).
    You can compile STXXL with -DSTXXL_DIRECT_IO_OFF to completely ignore stxxl::file::DIRECT (it's also used internally in several places).
    Stxxl may work on Cygwin (but that primarily depends on whether Cygwin implements everything used by Stxxl), but is not actively tested on that platform by us developers. There may be some more fixes needed for porting Stxxl to cygwin, patches welcome!


  • ropar

    Thanks for your help!

    I compiled STXXL with -DSTXXL_DIRECT_IO_OFF and I didn't run into any different problems on the first look.
    The reason for not using it onto Windows is that this would mean quite more additional work, since the rest of the project was developed on Unix. Right now I just want to make sure, that the project is portable to Cygwin and I am happy, it's working finally! So, thanks to you! Maybe I am going to take a deeper look into the consequences of using STXXL on Cygwin - but can't guarantee. In this case I would get back to you.