Last Comment Bug 780407 - xul.dll crashes in AvailableMemoryTracker::VirtualAllocHook with a PGO Pymake build
: xul.dll crashes in AvailableMemoryTracker::VirtualAllocHook with a PGO Pymake...
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: mozilla17
Assigned To: Siddharth Agarwal [:sid0] (inactive)
Depends on:
Blocks: 593585
  Show dependency treegraph
Reported: 2012-08-04 11:57 PDT by Siddharth Agarwal [:sid0] (inactive)
Modified: 2013-10-21 14:14 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

export MAKEFLAGS variables (1.99 KB, patch)
2012-08-04 14:34 PDT, Siddharth Agarwal [:sid0] (inactive)
khuey: review+
Details | Diff | Splinter Review

Description Siddharth Agarwal [:sid0] (inactive) 2012-08-04 11:57:02 PDT
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.
Comment 1 Kyle Huey [:khuey] ( 2012-08-04 12:03:55 PDT
There's an environment variable that's supposed to suppress that hook during the profiling run, which apparently isn't getting set.
Comment 2 Siddharth Agarwal [:sid0] (inactive) 2012-08-04 12:43:20 PDT
FTR, it's MOZ_PGO_INSTRUMENTED=1. Investigating why it isn't getting set for Pymake builds.
Comment 3 Siddharth Agarwal [:sid0] (inactive) 2012-08-04 13:37:18 PDT
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 Siddharth Agarwal [:sid0] (inactive) 2012-08-04 14:34:25 PDT
Created attachment 649031 [details] [diff] [review]
export MAKEFLAGS variables

This matches GNU make's behaviour and stops the build process from crashing.
Comment 5 Siddharth Agarwal [:sid0] (inactive) 2012-08-04 14:35:16 PDT
I also fixed a comment. That threw me in a loop for a bit.
Comment 6 Kyle Huey [:khuey] ( 2012-08-04 14:40:36 PDT
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 Siddharth Agarwal [:sid0] (inactive) 2012-08-04 14:53:16 PDT
I changed the name to concurrent_set.
Comment 8 Ryan VanderMeulen [:RyanVM] 2012-08-04 18:40:06 PDT
Comment 9 2013-10-20 01:09:09 PDT
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 Ted Mielczarek [:ted.mielczarek] 2013-10-21 12:09:04 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.