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)
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
Updated•14 years ago
|
Severity: normal → critical
blocking2.0: --- → beta7+
Priority: -- → P1
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → armenzg
Assignee | ||
Comment 1•14 years ago
|
||
I have given dvander access to one of our harware machines to debug this.
Status: NEW → ASSIGNED
Comment 2•14 years ago
|
||
(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.
Assignee | ||
Updated•14 years ago
|
Severity: critical → major
blocking2.0: beta7+ → ---
OS: Windows 7 → Windows Server 2003
Priority: P1 → P2
Assignee | ||
Comment 4•14 years ago
|
||
(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?
Assignee | ||
Comment 6•14 years ago
|
||
see bug 600373.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•