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)
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.
Reporter | ||
Comment 1•11 years ago
|
||
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"
Reporter | ||
Comment 2•11 years ago
|
||
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)
Assignee | ||
Comment 3•11 years ago
|
||
This seems to be an issue about disk space, not vmem usage. And it's definitely a blocker.
Severity: normal → blocker
Updated•11 years ago
|
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: catlee
Whiteboard: [buildduty]
Updated•11 years ago
|
Assignee: nobody → kmoir
Component: Release Engineering: Automation (General) → Release Engineering
QA Contact: catlee
Whiteboard: [buildduty]
Comment 4•11 years ago
|
||
I've clobbered the builder and am running a rebuild. However, the machine initially seemed to have enough space.
Comment 5•11 years ago
|
||
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
Assignee | ||
Updated•11 years ago
|
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
Assignee | ||
Comment 6•11 years ago
|
||
With image/, accessible/ and rdf/ not doing PGO anymore, we should re-measure the linker vmem usage.
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → ehsan
Reporter | ||
Comment 7•11 years ago
|
||
I suspect we may disable it on ipc and toolkit/crashreporter? those should not be perf sensitive.
Assignee | ||
Comment 8•11 years ago
|
||
(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).
Assignee | ||
Comment 9•11 years ago
|
||
I reopened the trees a few minutes ago.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 10•11 years ago
|
||
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.
Assignee | ||
Comment 11•11 years ago
|
||
(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.
Reporter | ||
Comment 12•11 years ago
|
||
fwiw, after ipc we are down to 3.2GB, that is a quite good improvement.
Comment 13•11 years ago
|
||
(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.
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•