Hi Mike, I will try to get a small testable set of rules/tupfile that can cause these problems. I have not hit the Broken pipe error though. Code changes to avoid chdir calls right now are very much in the alpha stage but shows that we can avoid calling chdir in windows in many cases. Right now it only solves the cases i work on. Thank you! Arun On Tuesday, July 25, 2017 at 8:48:43 AM UTC+5:30, [email protected] wrote: > > Hi Arun, thanks for taking the time to dig into this! > > On Thu, Jul 13, 2017 at 3:29 AM, arun.s <[email protected] > <javascript:>> wrote: > > Thanks to Kalrish i can now build tup in windows with mingw toolchain. I > > debugged this problem further and sure enough it is the chdir and > getcwd > > calls that are the source of problems. > > I've started to merge Kalrish's patches. Hopefully we can finish that > work soon to make it easier to test on Windows. > > > From msdn (i presume chdir internally calls SetCurrentDirectory): > > > >> Multithreaded applications and shared library code should not use the > >> GetCurrentDirectory function and should avoid using relative path > names. The > >> current directory state written by the SetCurrentDirectory function is > >> stored as a global variable in each process, therefore multithreaded > >> applications cannot reliably use this value without possible data > corruption > >> from other threads that may also be reading or setting this value. This > >> limitation also applies to the SetCurrentDirectoryand GetFullPathName > >> functions. The exception being when the application is guaranteed to be > >> running in a single thread, for example parsing file names from the > command > >> line argument string in the main thread prior to creating any > additional > >> threads. Using relative path names in multithreaded applications or > shared > >> library code can yield unpredictable results and is not supported. > > > > > > I have a fix that removes calls to fchdir or chdir (except in initial > scan) > > in tup source code, passing around absolute paths only, to get rid of > these > > aborts in windows. There are other minor changes as well. > > > > http://www.github.com/svark/tup is forked off kalrish's repo. > > Would you want to file a pull request for your fix? > > >> I keep running into these two errors when running tup on windows in > multi > >> threaded mode. > >> > >> >tup error: Unable to open directory for update work. > >> > >> > >> >chdir: No such file or directory > >> >tup error: Failed to fchdir in a compat wrapper function. > >> > >> I use tup v0.7.3-60-gd3bfa7c but I have encountered this in v0.7.5. > >> I use 0.7.3.* because it allows me to ignore PDB files. > >> > >> Has anyone else encountered these. It is difficult to reproduce this. > But > >> i face this very often to be frustrated by them. > >> More the threads more the chances of these aborts. Does anyone know of > any > >> workarounds? > > I've run several test cases in thousands of loops on Windows and > haven't hit these errors. Any idea what I would need to do to trigger > it? Does it only happen with specific types of rules? > > I have hit a different one, though: > > .tup/tmp/output-121: Broken pipe > tup error: Unable to open sub-process output file after the process > completed. > *** Command ID=121 failed: gcc -c foo.c -o outdir33\foo.o > > Have you seen this one? > > -Mike >
-- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
