The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla17

Status

()

Core
Build Config
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: sid0, Assigned: sid0)

Tracking

Trunk
mozilla17
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(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	
 	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.
There's an environment variable that's supposed to suppress that hook during the profiling run, which apparently isn't getting set.
(Assignee)

Comment 2

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

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.
(Assignee)

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
Status: NEW → ASSIGNED
Attachment #649031 - Flags: review?(khuey)
(Assignee)

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
(Assignee)

Comment 7

5 years ago
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
Component: Build Config → XPCOM
Component: XPCOM → Build Config
https://hg.mozilla.org/mozilla-central/rev/9453cf029b72
Status: ASSIGNED → RESOLVED
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.