On 6 March 2018 at 01:23, Rebecca Cran <rebecca@xxxxxxxxxxxx> wrote: > I've had a report that FIO on Windows (at least Server 2012 R2 and 2016) > hangs when the attached script is run. The point at which it hangs is > apparently random, and within the condvar (pthread-win32) calls. > > I've replicated the hang, but I don't have time to debug it so I was hoping > somebody on this mailing list might have time to dig into it and figure out > what's wrong. I'd like to look but I no longer have access to Windows machines beyond what you can get with Appveyor so I'd need quite a restricted test case to analyse this (see below for the problems I've been having). > The people I was talking to thought it might be due to FIO linking to > msvcrt.dll, which is old and not supposed to be used by applications - they > should use the CRT distributed with Visual C++, such as msvcr120.dll > instead. However, it appears that fixing this would take quite a lot of work > since while FIO is relatively straightforward to change, pthread-win32 > hasn't had a full release since 2012 and doesn't build under a current msys > environment due to duplicated symbols etc. It's true you're not supposed to link against the system msvcrt.dll (see https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 and https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/ ) however the MinGW folks have observed it can't really go away and seem to gear everything up for doing that and only use it for basic functionality (e.g. see http://mingw-users.1079350.n2.nabble.com/Which-msvcrt-dll-does-MinGW-use-tp7582968p7582969.html and https://ghc.haskell.org/trac/ghc/ticket/14537#comment:2 ). Since your commit back in Jan 2014 (https://github.com/axboe/fio/commit/9aa5fe3290fd49c70e498d5e072a5b27e1c3034f ) fio migrated from pthread-win32 to MinGW's internal winpthread (which seems to be alive as there's a commit from Jan 2018 - https://github.com/mirror/mingw-w64/commits/master/mingw-w64-libraries/winpthreads ). If we have a repeatable small test case we might be able to send it to the MinGW folks to look at... I tried out the python script but it seemed to be complaining about a whitespace issue. After fixing that up it's unclear exactly what fio command lines it runs. I think for others to dig in we'd need something less fiddly like the raw fio command lines that generate the hang. Is there any chance the mystery user could join the mailing list so they can answer questions directly? Ideally we'd need a job that works on files within a filesystem and ideally nice small files so it could go into an AppVeyor job... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
