Closed Bug 832992 Opened 11 years ago Closed 11 years ago

Enable temporarily reopening the tree by getting working Windows PGO builds

Categories

(Firefox Build System :: General, defect)

x86_64
Windows 7
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mak, Assigned: ehsan.akhgari)

References

Details

PGOCVT : fatal error PG0001: An unexpected internal error was detected in source file 'f:\dd\vctools\compiler\utc\src\tools\pogo\cvtpgd\cvtpgd.cpp', line 800.
PGOCVT : fatal error PG0001: An unexpected internal error was detected in source file 'f:\dd\vctools\compiler\utc\src\tools\pogo\cvtpgd\cvtpgd.cpp', line 858.

and much later:

   Creating library xul.lib and object xul.exp
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
Generating code
4631 of 220850 (  2.10%) profiled functions will be compiled for speed
e:\builds\moz2_slave\m-cen-w32-ntly\build\layout\style\nscssscanner.cpp(441) : warning C4789: destination of memory copy is too small
e:\builds\moz2_slave\m-cen-w32-ntly\build\layout\style\nscssparser.cpp(1159) : warning C4748: /GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function
e:\builds\moz2_slave\m-cen-w32-ntly\build\obj-firefox\dom\bindings\SVGViewElementBinding.cpp : fatal error C1083: Cannot open compiler intermediate file: '..\..\dom\bindings\SVGViewElementBinding.obj': Not enough space
LINK : fatal error LNK1257: code generation failed
TinderboxPrint: linker max vsize: 3939495936


Not how much we are near the vsize limit (again), I hoper we are not seeing the return of bug 709480.
https://tbpl.mozilla.org/php/getParsedLog.php?id=18987969&tree=Firefox
WINNT 5.2 mozilla-central nightly on 2013-01-21 03:10:13 PST for push 91b9995f9ac7
slave: w64-ix-slave101
Summary: Nightly PGO build fails with error "Not enough space → Nightly PGO build fails with error "Not enough space"
sorry I pressed enter too early while filing the bug. What I meant is that in bug 709480 we were near 3GB of vsize, limit for our 32 bit builders.
now we are at 3939495936 that is quite near the full 4GB limit of win64 builders (using the win32 toolchain)
This seems to be an issue about disk space, not vmem usage.  And it's definitely a blocker.
Severity: normal → blocker
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: catlee
Whiteboard: [buildduty]
Assignee: nobody → kmoir
Component: Release Engineering: Automation (General) → Release Engineering
QA Contact: catlee
Whiteboard: [buildduty]
I've clobbered the builder and am running a rebuild.  However, the machine initially seemed to have enough space.
Yeah, it'd be pretty sweet if that was just disk space, but it's not. As googling that pair of error messages will tell you, with things like us in 2010 in http://connect.microsoft.com/VisualStudio/feedback/details/581207/visual-studio-2005-sp1-reproducible-linker-error-lkn1257-caused-by-c1083, that's the start (actually, the second instance, since the profiling branch hit https://tbpl.mozilla.org/php/getParsedLog.php?id=18965832&tree=Profiling yesterday) of us needing to deploy all the things that we've been planning to do once we hit the 4GB limit.
Assignee: kmoir → nobody
Component: Release Engineering → Build Config
Product: mozilla.org → Core
Summary: Nightly PGO build fails with error "Not enough space" → Windows PGO build fails with "LINK : fatal error LNK1257: code generation failed" after "fatal error C1083: Cannot open compiler intermediate file: SVGViewElementBinding.obj': Not enough space"
Version: other → Trunk
Summary: Windows PGO build fails with "LINK : fatal error LNK1257: code generation failed" after "fatal error C1083: Cannot open compiler intermediate file: SVGViewElementBinding.obj': Not enough space" → Enable temporarily reopening the tree by getting working Windows PGO builds
Depends on: 833097
Depends on: 833099
Depends on: 833101
With image/, accessible/ and rdf/ not doing PGO anymore, we should re-measure the linker vmem usage.
Assignee: nobody → ehsan
Depends on: 833118
Depends on: 833189
Depends on: 833190
Depends on: 833191
Depends on: 833193
Depends on: 833194
Depends on: 833196
Depends on: 833197
Depends on: 711386
I suspect we may disable it on ipc and toolkit/crashreporter? those should not be perf sensitive.
Depends on: 710840
Depends on: 833359
(In reply to comment #7)
> I suspect we may disable it on ipc and toolkit/crashreporter? those should not
> be perf sensitive.

But there's also very little code in toolkit/crashreporter which is built as part of libxul (nsExceptionHandler.cpp, LoadLibraryRemote.cpp and InjectCrashReporter.cpp IINM).
I reopened the trees a few minutes ago.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
I suggest that we should have a long-term plan to split xul.dll into xul.part1.dll, xul.part2.dll ... IF we do not want to drop PGO.
(In reply to comment #10)
> I suggest that we should have a long-term plan to split xul.dll into
> xul.part1.dll, xul.part2.dll ... IF we do not want to drop PGO.

That would be a tremendous technical challenge and would defeat the purpose of unifying libxul in the first place.  We have not yet explored all other avenues.
fwiw, after ipc we are down to 3.2GB, that is a quite good improvement.
(In reply to :Ehsan Akhgari from comment #11)
> (In reply to comment #10)
> > I suggest that we should have a long-term plan to split xul.dll into
> > xul.part1.dll, xul.part2.dll ... IF we do not want to drop PGO.
> 
> That would be a tremendous technical challenge and would defeat the purpose
> of unifying libxul in the first place.  We have not yet explored all other
> avenues.

Then periodically disabling PGO on more and more components in libxul is necessary.
One day PGO will be 99.99% dropped.

(In reply to Marco Bonardo [:mak] from comment #12)
> fwiw, after ipc we are down to 3.2GB, that is a quite good improvement.

That's amazing.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.