[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #34, bug#64806 (group make): That weird problem is with a particular build of Windows port of GNU Make, and it is not clear to me on what OS the error was seem. But yes, it sounds like it's a separate issue. ___ Reply

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #33, bug#64806 (group make): The original problem statement by Michael Davidsaver (comment #1 - comment #11) suggested some apparent corruption of a command line argument that carries the mutex handle number: > make: *** invalid output sync mutex: �*V8�. Stop. I am afraid,

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #32, bug#64806 (group make): I don't think I understand what you mean by "change management aspect", and why the behavior discussed here doesn't have much to do with the original problem report. Please elaborate. ___

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #31, bug#64806 (group make): Indeed, probably the smallest change would be just _not_ closing the handle in _osync_clear()_ [w32os.c] i.e., relying on Windows to auto-close the handle upon process termination, without any other change in the control flow (this is the workaround

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #30, bug#64806 (group make): Thanks for the footwork and detailed information. This is for Paul to decide, eventually, but I personally would prefer a simpler way of calling osync_clear on MS-Windows only in the top-level Make. AFAIU, this should solve the problem without

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #29, bug#64806 (group make): As proposed by Eli, I have investigated the process of mutex creation and inheritance; please find below a brief summary regarding the implementation of key functions in _posixos.c_ and _w32os.c_, a proposal for bringing the two approaches closer to

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #28, bug#64806 (group make): Thanks, this is important information. So I think the next step is to understand which call to osync_clear closes the handle. Maybe we shouldn't make that call, at least on Windows? Also, this only happens sometimes, right? That is, -Otarget

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #27, bug#64806 (group make): I went on with analysis of the situation as follows. When processes are apparently hung, they are waiting for a handle whose numeric value equals the handle of the mutex created by the root process (0x128 in the example below). At this point

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #26, bug#64806 (group make): Killing sub-processes one by one did not change the situation, the rest of processes stayed hung. ___ Reply to this item at:

Re: [bug #64806] "invalid output sync mutex" on windows

> Date: Mon, 15 Jan 2024 12:37:42 -0500 > From: Ken Brown > > This is a long shot, but I had a problem a year ago with parallel make > on Cygwin occasionally hanging. The solution turned out to be to force > make's jobserver to use pipes instead of fifos. If you want to try > this, pass

Re: [bug #64806] "invalid output sync mutex" on windows

This is a long shot, but I had a problem a year ago with parallel make on Cygwin occasionally hanging. The solution turned out to be to force make's jobserver to use pipes instead of fifos. If you want to try this, pass make the option '--jobserver-style=pipe'. Ken

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #25, bug#64806 (group make): The \Device\ConDrv thing is strange, not sure what to make of that. The one process where the handle is shown as "Mutant" is correct, AFAIU. Maybe it means the child processes actually released the mutex, but then why does the parent keep waiting,

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #24, bug#64806 (group make): Looked for this handle by invoking "handle -a -p mingw" then, kept only those lines of the output where the handle 120 was mentioned; this is the remaining output: mingw32-make.exe pid: 7496 120: Mutant mingw32-make.exe pid: 13060 120:

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #23, bug#64806 (group make): Do any other processes of those involved in the hang have this same mutex handle open? ___ Reply to this item at:

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #22, bug#64806 (group make): I am afraid, we are now somewhat over my Windows competence, here is what I was able to derive. Variable osync_handle is (HANDLE) 0x120: (gdb) attach 14472 (gdb) thread 1 (gdb) bt #0 0x771f2bcc in ntdll!ZwWaitForSingleObject () from

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #21, bug#64806 (group make): Can you use ProcessExplorer (or some other SysInternals tool) to find out which process, if any holds the handle that is the value of osync_handle, the handle for which osync_acquire is waiting in the instances that are hung?

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #20, bug#64806 (group make): Checked for three other make processes: I would say that they are in the same situation (the processes on the screenshot are still running). =Summary= * 7496 (T1: *process_wait_for_multiple_objects*() at src/w32/subproc/sub_proc.c:89) *

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #19, bug#64806 (group make): When the stuff hangs, can you use ProcessExplorer to see which mutexes are actually used by these Make processes, and how many of them are used? You can find the code which manipulates the mutexes in src/w32/w32os.c (look for the osync_* functions

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #18, bug#64806 (group make): Very strange. Looks like the parent process is waiting for the child to finish, and the child process cannot acquire the mutex and also waits. Are all of the 8 sub-make's in the same situation? FWIW, I tried to run the Makefile you sent on my

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #17, bug#64806 (group make): All the 8 processes seem to be hung: see attached screenshot from Process Explorer. Apparently there is a "root" process, that has eight children, who each have 1-1 children. Now did a more systematic investigation along the process creation tree

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #16, bug#64806 (group make): >From the backtrace of the hung process, it looks like we wait forever for a mutex to be released, which means some child process that holds the mutex exited. But the mutex is never released. Do you see any other related sub-processes that are hung

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #15, bug#64806 (group make): Having placed a breakpoint on the error() function, it seems that the "mingw32-make: *** [Makefile:7: cmp3] Error 130" error message comes from this function call chain: #0 error (flocp=flocp@entry=0x0, len=len@entry=40, fmt=fmt@entry=0x60982d

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #14, bug#64806 (group make): I can confirm Eli's comment that the relevant difference is apparently using a mutex for synchronization, not being 32 or 64 bit. MSys2 comes with several "environments", the make binary reported hanging was from the "MINGW32" environment: $ file

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #13, bug#64806 (group make): It would be helpful to understand which code cause the "Error 130" message to be displayed, so as to allow interpreting that error, which might give us some hint about what's going on. If 130 is a value obtained from GetLastError, then its meaning

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #12, bug#64806 (group make): Hi all, I've recently encountered some undesired behavior which is likely related to this open issue; attaching description of the phenomenon with a tiny project where it consistently appears. The environment I used is the MSYS2 distribution

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #11, bug #64806 (project make): The utility is built using the MingW tool set. I would not personally recommend doing so. ___ Reply to this item at:

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #10, bug #64806 (project make): 5.32.1.1-64bit gmake.exe 14/03/2019 - EPICS base 7.0.7 builds fine with this. 5.38.0.1-64bit EPICS base constains a file 'print.cpp', which should of course compile to 'print.obj'. But the make utility puts this in upper case so the

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #9, bug #64806 (project make): > Is the brechtsanders build a 32-bit executable or a 64-bit executable? 64-bit as I read it. bin/make.exe:PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows, 10 sections

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #8, bug #64806 (project make): Is the brechtsanders build a 32-bit executable or a 64-bit executable? If it's a 64-bit executable, maybe the problem only rears its ugly head in a 64-bit build, because the ezwinports stuff is 32-bit.

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #7, bug #64806 (project make): > This bug report lacks a reproduction recipe ... The closest which I think I can come to providing such a recipe is in WINE where "-Otarget -j" works with the ezwinports build, but not with the brechtsanders/winlibs_mingw build. detailed

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #6, bug #64806 (project make): > This bug report lacks a reproduction recipe ... Yes, I know. Unfortunately (well, in this instance ;) ) I run Linux exclusively on my personal systems and only interact with windows via continuous integration builds. Troubleshooting with CI

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #5, bug #64806 (project make): Quoting @shawnlaffan from https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/148#issuecomment-1783929512 > The root cause of the issue seems to be that the make executables do not support recursive calls when they have been renamed.

[bug #64806] "invalid output sync mutex" on windows

Update of bug #64806 (project make): Triage Status:None => Need Info ___ Follow-up Comment #4: This bug report lacks a reproduction recipe, preferably one that doesn't require to download huge

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #3, bug #64806 (project make): "choco install make" is stated to be a build from https://sourceforge.net/projects/ezwinports https://bitbucket.org/xoviat/chocolatey-packages/src/master/make/4.4.1/tools/VERIFICATION.txt At this point I have am not sure I can provide any

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #2, bug #64806 (project make): Following the trail from the strawberry perl installer leads to: https://github.com/brechtsanders/winlibs_mingw/issues/174 ___ Reply to this item at:

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #1, bug #64806 (project make): Correction. We intended to use make 4.4.1 via chocolatey. It appears that the latest strawberry perl release 5.38.0.1 now installs "make.exe". Previous releases only install "gmake.exe". This executable also identifies as make 4.4.1, but I am

[bug #64806] "invalid output sync mutex" on windows

URL: Summary: "invalid output sync mutex" on windows Group: make Submitter: mdavidsaver Submitted: Sun 22 Oct 2023 09:38:22 PM UTC Severity: 3 - Normal Item