[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 (https:

[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 /m

[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 #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 74

[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) * 370

[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 C:\WINDOWS\S

[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: Fi

[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:

[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 Process

[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 e

[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 m

[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, wh