I've seen this a couple of times now. I'm running on a machine with 4x2 cpus with -j8. When attach to the hung process in a debugger it seems to be hung in RtlTryEnterCriticalSection. Here's the stack: ntdll_77340000!RtlTryEnterCriticalSection+0x17 ntdll_77340000!RtlpAllocateHeap+0x136 ntdll_77340000!RtlAllocateHeap+0x23a KERNELBASE!FindNextFileW+0x90 KERNELBASE!FindNextFileA+0x2a WARNING: Stack unwind information not available. Following frames may be wrong. msys_1_0!readdir+0xbd make+0x434f make+0x44b5 make+0x45a2 make+0xcd9f make+0xbd0b make+0x1a4e4 make+0x19a00 make+0x19a71 make+0x19702 make+0x12a6e msys_1_0!_assert+0x39dc msys_1_0!dll_crt0+0x133 msys_1_0!dll_crt0__FP11per_process+0x34 make+0x22814 Perhaps the problem is heap corruption.
This is with MozillaBuild 1.4
I also sometimes get *** INTERNAL: readdir: Bad file number
gmake-windows hanging during parallel builds is a known PITA, and not one that Ted or I is likely to fix, given the existence of pymake. I recommend WONTFIX (and/or filing this upstream with gmake or MSYS), unless you want to investigate it yourself.
Yeah, I sort of expected that. I'd like to keep this bug open to record info as I become motivated to investigate it.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #4) > Yeah, I sort of expected that. I'd like to keep this bug open to record info > as I become motivated to investigate it. obsolete?
We dropped support for building with gmake on Windows in bug 828317.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.