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

[Gergely Pinter]

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 /mingw32/bin/mingw32-make.exe
/mingw32/bin/mingw32-make.exe: PE32 executable (console) Intel 80386 (stripped
to external PDB), for MS Windows, 11 sections

This is the make from "MSYS" environment, that runs fine:

$ file /bin/make.exe
/bin/make.exe: PE32+ executable (console) x86-64 (stripped to external PDB),
for MS Windows, 10 sections

According to the comment, I also checked with the "MINGW64" environment:

$ file /mingw64/bin/mingw32-make.exe
/mingw64/bin/mingw32-make.exe: PE32+ executable (console) x86-64 (stripped to
external PDB), for MS Windows, 12 sections

This third binary also hangs, but with this binary I also saw this once (in
which case the compilation went on):

DEP src99.c [cmp3]
DEP src99.c [cmp5]
mingw32-make[1]: warning: Cannot acquire output lock, disabling output sync.
CC  src0.c [cmp0]
CC  src1.c [cmp0]

It may be worth mentioning that the hang occurs exactly once having finished
creating dependency files whose creation was triggered by an "include"
directive and before starting actual compilation (first creating .d files with
"-Onone", then calling "mingw32-make -s -j 8 -Otarget" with already existing
.d files successfully compiles all 1000 files in the example).

Tried to investigate what is going on in hung processes: (i) re-compiled
mingw32-make from the MSys2 package with debug symbols, (ii) called
"mingw32-make -s -j 8 -Otarget" as usually, (iii) waited until processes hang,
(iv) attached gdb to one of the processes and dumped backtrace of both
threads:


(gdb) info threads
  Id   Target Id          Frame
  1    Thread 4680.0x57ec 0x771f315c in ntdll!ZwWaitForMultipleObjects ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
* 2    Thread 4680.0x16b0 0x771f4f21 in ntdll!DbgBreakPoint ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
(gdb) bt
#0  0x771f4f21 in ntdll!DbgBreakPoint () from C:\WINDOWS\SysWOW64\ntdll.dll
#1  0x7722dbc9 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
#2  0xdb1ac4d4 in ?? ()
#3  0x7722db90 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
#4  0x767bfcc9 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SysWOW64\kernel32.dll
#5  0x771e7c6e in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
#6  0x771e7c3e in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
#7  0x00000000 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 4680.0x57ec)]
#0  0x771f315c in ntdll!ZwWaitForMultipleObjects ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
(gdb) bt
#0  0x771f315c in ntdll!ZwWaitForMultipleObjects ()
   from C:\WINDOWS\SysWOW64\ntdll.dll
#1  0x76304de3 in WaitForMultipleObjectsEx ()
   from C:\WINDOWS\SysWOW64\KernelBase.dll
#2  0x76304cc8 in WaitForMultipleObjects ()
   from C:\WINDOWS\SysWOW64\KernelBase.dll
#3  0x005f7ad5 in process_wait_for_multiple_objects (nCount=8,
    lpHandles=0x19faf40, bWaitAll=0, dwMilliseconds=4294967295)
    at src/w32/subproc/sub_proc.c:89
#4  0x005f7c20 in process_wait_for_any_private (block=block@entry=1,
    pdwWaitStatus=pdwWaitStatus@entry=0x19fefbc)
    at src/w32/subproc/sub_proc.c:204
#5  0x005f8ad1 in process_wait_for_any (block=block@entry=1,
    pdwWaitStatus=pdwWaitStatus@entry=0x19fefbc)
    at src/w32/subproc/sub_proc.c:307
#6  0x005e2659 in reap_children (block=<optimized out>, err=err@entry=0)
    at src/job.c:848
#7  0x005f06ce in update_goal_chain (goaldeps=<optimized out>)
    at src/remake.c:142
#8  0x006043ce in main (argc=<optimized out>, argv=<optimized out>,
    envp=<optimized out>) at src/main.c:2921


I hope this provides some information; unfortunately I am not familiar with
debugging under Windows or the Windows API in general.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64806>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/