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

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Rain [:rain1] (inactive)]

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	
 	0054070d()	
>	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.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

There's an environment variable that's supposed to suppress that hook during the profiling run, which apparently isn't getting set.

Comment 2

[Rain [:rain1] (inactive)]

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

Comment 3

[Rain [:rain1] (inactive)]

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

[Rain [:rain1] (inactive)]

Attachment: export MAKEFLAGS variables

This matches GNU make's behaviour and stops the build process from crashing.

Comment 5

[Rain [:rain1] (inactive)]

I also fixed a comment. That threw me in a loop for a bit.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 7

[Rain [:rain1] (inactive)]

I changed the name to concurrent_set.

http://hg.mozilla.org/users/bsmedberg_mozilla.com/pymake/rev/1e80cc5ed414
http://hg.mozilla.org/integration/mozilla-inbound/rev/9453cf029b72

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9453cf029b72

Comment 9

[[e-mail]]

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?

Comment 10

[(not currently active) Ted Mielczarek]

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.