The default bug view has changed. See this FAQ.

xul.dll crashes in AvailableMemoryTracker::VirtualAllocHook with a PGO Pymake build

RESOLVED FIXED in mozilla17



Build Config
5 years ago
4 years ago


(Reporter: sid0, Assigned: sid0)


Windows 7

Firefox Tracking Flags

(Not tracked)



(1 attachment)

A Pymake build with PGO enabled on a build slave seems to result in a broken xul.dll on the first pass. The dll crashes in AvailableMemoryTracker.cpp if e.g. xpcshell.exe is invoked.

VC10 produces the following stack:

First-chance exception at 0x632f1fb8 (pgort100.dll) in xpcshell.exe: 0xC00000FD: Stack overflow.
Unhandled exception at 0x632f1fb8 (pgort100.dll) in xpcshell.exe: 0xC00000FD: Stack overflow.

 	pgort100.dll!IbPGCGrowAllocation()  + 0x92 bytes	
 	pgort100.dll!PVPLELookup()  + 0x56 bytes	
>	xul.dll!`anonymous namespace'::VirtualAllocHook(void * aAddress=, unsigned long aSize=, unsigned long aAllocationType=, unsigned long aProtect=)  Line 234 + 0x1d bytes	C++

ccing some people who might have an idea about this, and why it happens on pymake but (presumably) not on gmake.
There's an environment variable that's supposed to suppress that hook during the profiling run, which apparently isn't getting set.

Comment 2

5 years ago
FTR, it's MOZ_PGO_INSTRUMENTED=1. Investigating why it isn't getting set for Pymake builds.

Comment 3

5 years ago
GNU make exports variables passed over the command line (note: different from env vars) by default, but Pymake doesn't. That's causing the problem.

Comment 4

5 years ago
Created attachment 649031 [details] [diff] [review]
export MAKEFLAGS variables

This matches GNU make's behaviour and stops the build process from crashing.
Assignee: nobody → sagarwal
Attachment #649031 - Flags: review?(khuey)

Comment 5

5 years ago
I also fixed a comment. That threw me in a loop for a bit.
Comment on attachment 649031 [details] [diff] [review]
export MAKEFLAGS variables

Review of attachment 649031 [details] [diff] [review]:

r=me if you change 'single' to be a better variable name.
Attachment #649031 - Flags: review?(khuey) → review+
Component: XPCOM → Build Config

Comment 7

5 years ago
I changed the name to concurrent_set.
Component: Build Config → XPCOM
Component: XPCOM → Build Config
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17

Comment 9

4 years ago
I meet this bug again. trunk + vs2013 + mozbuild1.8 .

I run “pymake libs -j3 MOZ_PROFILE_GENERATE=1 MOZ_PGO_INSTRUMENTED=1” manually. What did I miss?
I'm not sure why you're running the individual compile phases manually. Just do a top-level PGO build. If you don't run the second phase of the build you haven't actually built a PGO build.
You need to log in before you can comment on or make changes to this bug.