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. вторник, 7 сентября 2021 г. в 02:22:02 UTC+3, kmickle: > Hi, Mike. Thank you very much for your attention. > > I've scooped a ProcMon report as you suggested. You may have a look at it > here: > https://disk.yandex.ru/d/7zUEQSTl8qeBTg > > I haven't had time yet to delve deep into it, but a brief skim revealed > nothing of value. There is some perk in 'tup' with spaces in file names > (see Events ##652–655), but that is not necessarily an error. Moving 'tup' > and 'lilypond' to locations with no spaces and non-ASCII symbols has no > effect on the problem. > > One other feature is a fair amount of failed > "QueryNormalizedNameInformationFile" core calls. > > I'll keep you updated in case I notice something else. > понедельник, 6 сентября 2021 г. в 04:24:31 UTC+3, [email protected]: > >> Thanks for the report! >> >> I tried to reproduce this with your example, but I'm having trouble >> getting it to freeze. I'm using the same versions of tup & LilyPond: >> >> $ tup >> [ tup ] [0.016s] Scanning filesystem... >> [ tup ] [0.031s] Reading in new environment variables... >> [ tup ] [0.047s] Parsing Tupfiles... >> 0) [0.000s] . >> [ ] 100% >> [ tup ] [0.047s] No files to delete. >> [ tup ] [0.047s] Generating .gitignore files... >> [ tup ] [0.062s] Executing Commands... >> 0) [0.906s] lilypond.exe test.ly >> GNU LilyPond 2.22.1 >> Processing `test.ly' >> Parsing... >> test.ly:1: warning: no \version statement found, please add >> >> \version "2.22.1" >> >> for future compatibility >> Interpreting music... >> Preprocessing graphical objects... >> Finding the ideal number of pages... >> Fitting music on 1 page... >> Drawing systems... >> Converting to `test.pdf'... >> Success: compilation successfully completed >> [ ] 100% >> [ tup ] [0.984s] Updated. >> >> I did need to add some extra exclusions to ignore the LilyPond & >> fontconfig fonts caches: >> >> : *.ly |> lilypond.exe %f |> %B.pdf ^.log ^lilypond-fonts.cache >> ^.cache/fontconfig >> >> But otherwise it appears to work fine in both a bourne shell and the cmd >> shell. Is it possible the gspawn-win32-helper-console.exe remains around as >> a server process on your machine, but not on mine? There was a similar >> problem with mspdbsrv.exe, where that process would get created as a >> long-running server process by the first tool that wanted to use it. If >> that was created under tup, then tup would wait around forever for it to >> exit. If that is the culprit, we may just need to add another check for tup >> to ignore injecting into that process. >> >> However, while I do see gspawn-win32-helper-console.exe get used in >> ProcMon, it exits afterward and tup exits successfully. So, it's possible >> that there's a different issue. >> >> Can you try running yours under ProcMon and seeing if there are any >> clues? Maybe filter on tup.exe and/or gspawn-win32-helper-console.exe and >> lilypond.exe to see why a subprocess might be hanging around. Sorry I don't >> have a better suggestion at the moment. >> >> -Mike >> >> On Sun, Sep 5, 2021 at 3:32 PM kmickle <[email protected]> wrote: >> >>> >>> Good day >>> >>> I've been using tup to build my LilyPond ( https://lilypond.org/ ) >>> based project. Lilypond processes LY files (pulling in optional LYI and SCM >>> dependencies) and generates PDFs and LOGs. In other words, behaves much >>> like a C or a LaTeX compiler. It works just fine under Linux, but on >>> Windows the following happens: >>> >>> 1. Tup freezes at 0% when "Executing commands...". The first J (J = >>> processor core count) commands seem to execute successfully and produce >>> outputs named " ****-tmp-*** '; >>> 2. Tup hangs indefinitely until aborted; >>> 3. On abort, tup throws the following J error messages: " >>> .tup/tmp/output-***: Broken pipe >>> tup error: Unable to open sub-process output file after the process >>> completed."; >>> 4. After the abort, J frozen processes named >>> 'gspawn-win32-helper-console.exe' (32-bit) remain, blocking the tup >>> database until killed manually. >>> >>> I suspect that might be a bug in tup. This only occurs on Windows. I've >>> ensured tup works with the C compiler on the system, so the problem is >>> tup-lilypond incompatibility. I've also made sure Lilypond runs fine on its >>> own. >>> >>> Minimal Example: >>> ===== >>> File: test.ly >>> ---- >>> \fixed c { c d e } >>> ===== >>> File: Tupfile >>> ---- >>> : *.ly |> lilypond.exe %f |> %B.pdf ^.log >>> ===== >>> >>> Please let me know if you know a way to fix it or whenever I may assist >>> somehow in diagnostics and debugging. >>> >>> -- >>> -- >>> 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/f25ff722-14c5-4bbb-9e51-2bd0841129efn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/tup-users/f25ff722-14c5-4bbb-9e51-2bd0841129efn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- 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/3b0f6d6b-668d-4881-a6c1-db47f6ee2ce5n%40googlegroups.com.
