Gave it a run. The following happened: tup did not block GhostScript, and it terminated correctly. However, tup was unable to detect the files GS wrote to, so the build recipe failed. It seems the hook on GS is now non-functional.
Here's the trace: https://yadi.sk/d/niplINUFbxnONw пятница, 24 сентября 2021 г. в 10:53:18 UTC+3, [email protected]: > On Thu, Sep 9, 2021 at 2:57 PM kmickle <[email protected]> wrote: > >> Upd.: >> GhostScript has been confirmed to be the source of the problem. Any >> GhostScript invocations from tup freeze, while LilyPond works fine with >> other output types. >> >> I have tried using the freshest manually downloaded binaries of >> GhostScript x64 instead of the bundled ones, but the 'gswin64' version >> still freezes, and 'gswin64c' crashes. It does work outside of tup. >> >> There is something amiss with hooked GhostScript. >> >> > Thanks so much for getting the ProcMon reports and digging into it more, > that was very helpful. Although I couldn't get LilyPond to fail for me, I > think I was able to reproduce what you were seeing by trying to invoke > Ghostscript directly (at least, it generated a similar looking ProcMon > report). Tup was hanging in a call to WaitForInputIdle(), which was given > an infinite timeout. This call was present since the initial Windows > support, but curiously, it hasn't ever worked. WaitForInputIdle() is odd > for a Windows function in that it returns 0 for success (most Windows > functions are backwards and use 0 for failure). Tup was expecting it to > match other Windows-style functions, and saw that the return value wasn't > 0, and continued on. > > For every other process that tup hooks in test cases, the function fails > immediately with a return value of -1. In the case of Ghostscript, it > doesn't fail immediately, but instead waits until the timeout to return. > Due to the infinite timeout that was used, this meant tup was hanging > indefinitely. I'm not sure exactly why Ghostscript goes the route of a > timeout, but the error code when spawning something like gcc is > ERROR_NOT_GUI_PROCESS. Maybe Ghostscript qualifies as a gui process, so > Windows is waiting for it to "start"? But we spawn it suspended, so it > never gets there, I think. > > Since the call doesn't appear to be doing what's intended, I tried > removing it, and all test cases still pass. I was also able to run > Ghostscript directly (and LilyPond still) with this change. Can you try > http://gittup.org/tup/win32/tup-v0.7.11-50-gb4e2c649.zip and see if that > works for you? > > Thanks again, > -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]. To view this discussion on the web visit https://groups.google.com/d/msgid/tup-users/0868f632-bfff-475d-98a1-5c7f14191f41n%40googlegroups.com.
