Status

RESOLVED WONTFIX
9 years ago
6 months ago

People

(Reporter: jrmuizel, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
This is with MozillaBuild 1.4
(Reporter)

Comment 2

9 years ago
I also sometimes get *** INTERNAL: readdir: Bad file number

Comment 3

9 years ago
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.
(Reporter)

Comment 4

9 years ago
Yeah, I sort of expected that. I'd like to keep this bug open to record info as I become motivated to investigate it.

Comment 5

5 years ago
(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

Updated

6 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.