[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: Segmentation Fault on Exported Resursively Expanded Variable

On Mon, Jan 15, 2024 at 9:02 AM MIAOW Miao wrote: > Here is a Makefile that can reproduce the segmentation fault: > > THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello) > export THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR > > all: ; echo "abc" > > Commands log: > > user@fedora:~$ make >

Re: Segmentation Fault on Exported Resursively Expanded Variable

I was not able to reproduce it with Make 4.1 or Make 4.3. I don't have the original Make 4.4.1, but I had a binary of my fork 4.4.1h2 from https://github.com/henca/Henriks-make and got a segfault in that one which probably means that I have been able to reproduce the report from Miao. Opening a

Re: Segmentation Fault on Exported Resursively Expanded Variable

On Mon, 2024-01-15 at 11:21 +, MIAOW Miao wrote: > I found name of exported resursively expanded variable with $(shell > ...) cannot be too long in gnu make version >= 4.4, otherwise a > segmentation fault is triggled. I'm not sure if variable-name-too- > long is a bug. However, make is >

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

Segmentation Fault on Exported Resursively Expanded Variable

Hi, I found name of exported resursively expanded variable with $(shell ...) cannot be too long in gnu make version >= 4.4, otherwise a segmentation fault is triggled. I'm not sure if variable-name-too-long is a bug. However, make is supposed to tell me what's going wrong. Here is a Makefile

[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