Closed Bug 598663 Opened 14 years ago Closed 14 years ago

PGO linker crashing on TM Windows opt builds

Categories

(Release Engineering :: General, defect, P2)

x86
Windows Server 2003

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: dvander, Assigned: armenzg)

References

()

Details

Started happening on the tracemonkey tree after bug 591836 landed. NEXT ERROR e:\builds\moz2_slave\tracemonkey-win32\build\js\src\methodjit\compiler.cpp(2020) : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'F:\SP\vctools\compiler\utc\src\P2\main.c[0x10D0FA3C:0x10D0FA3C]', line 182) To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage
Severity: normal → critical
blocking2.0: --- → beta7+
Priority: -- → P1
Assignee: nobody → armenzg
I have given dvander access to one of our harware machines to debug this.
Status: NEW → ASSIGNED
(In reply to comment #1) > I have given dvander access to one of our harware machines to debug this. I am not sure how a JS engineer is going to help debug a C++ linker/compiler error. I think the first thing to do is check whether a PGO build works on 64-bit Windows.
So the last time we hit something like this (Bug 582335) we fixed it by doing some build system hackery to "unroll" the way we link libxul on Windows (Bug 522770). We only did one level of this (now, instead of linking xul.dll from gklayout.lib, gkwidget.lib, etc. we link it from gkconbase.lib, gkdombase.lib, etc). The patch in Bug 584474 unrolls the linking all the way so that we always link directly to the object files. tl;dr: let's try the patch from bug 584474 on a builder and see what happens.
Severity: critical → major
blocking2.0: beta7+ → ---
OS: Windows 7 → Windows Server 2003
Priority: P1 → P2
(In reply to comment #1) > I have given dvander access to one of our harware machines to debug this. dvander is done with the machine. (In reply to comment #3) > So the last time we hit something like this (Bug 582335) we fixed it by doing > some build system hackery to "unroll" the way we link libxul on Windows (Bug > 522770). We only did one level of this (now, instead of linking xul.dll from > gklayout.lib, gkwidget.lib, etc. we link it from gkconbase.lib, gkdombase.lib, > etc). The patch in Bug 584474 unrolls the linking all the way so that we > always link directly to the object files. > > tl;dr: let's try the patch from bug 584474 on a builder and see what happens. Hi khuey, I have tried your approach by: * takind dvander's changeset 1af8f0c895bc * added patches from bug 584474 * pushed to try and the build failed: * http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1285602002.1285604782.26197.gz&fulltext=1 * http://hg.mozilla.org/try/rev/349958f7cda5 Anything else that you think I could try?
I thought shaver had already figured this out?
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Blocks: 601109
No longer blocks: 601109
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.