Closed
Bug 780407
Opened 12 years ago
Closed 12 years ago
xul.dll crashes in AvailableMemoryTracker::VirtualAllocHook with a PGO Pymake build
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla17
People
(Reporter: rain1, Assigned: rain1)
References
Details
Attachments
(1 file)
1.99 KB,
patch
|
khuey
:
review+
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
FTR, it's MOZ_PGO_INSTRUMENTED=1. Investigating why it isn't getting set for Pymake builds.
Assignee | ||
Comment 3•12 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•12 years ago
|
||
This matches GNU make's behaviour and stops the build process from crashing.
Assignee | ||
Comment 5•12 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•12 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
Updated•12 years ago
|
Component: XPCOM → Build Config
Comment 8•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Comment 9•11 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?
Comment 10•11 years ago
|
||
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.
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•