win_8_perf_bisect Fails with Internal Compiler Error |
|||
Issue descriptionI submitted a job to the win-8 perfbot twice, failing in the same way both times. https://build.chromium.org/p/tryserver.chromium.perf/builders/win_8_perf_bisect/builds/1904 FAILED: C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-with-manifests environment.x86 True performance_browser_tests.exe "C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-wrapper environment.x86 False link.exe /nologo /OUT:performance_browser_tests.exe @performance_browser_tests.exe.rsp" 1 mt.exe rc.exe "obj\chrome\performance_browser_tests.performance_browser_tests.exe.intermediate.manifest" obj\chrome\performance_browser_tests.performance_browser_tests.exe.generated.manifest ..\..\build\win\compatibility.manifest LibDef: Total time = 0.047s OptRef: Total time = 0.343s c:\b\depot_tools\win_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97\vc\include\memory(1334) : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 249) 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!CloseTypeServerPDB()+0x4af06 link!CloseTypeServerPDB()+0x4af06 link!CloseTypeServerPDB()+0x4bf10
,
Apr 8 2016
Looks like it ran out of memory while linking. Issue 601699 is for building with more RAM.
,
Apr 11 2016
Internal compiler errors are, by Microsoft's definition, always compiler bugs. They might make a philosophical exception if out-of-memory is the cause, but they should be reporting it as such. The linked failure was from a build that was synced to 696328b73733342f0335b1f3e6b1064fbfea40ce, a change from April 6th. I can try investigating that locally. If I can reproduce the failure then I will report it. 16 GB is a bit light on memory. With that much RAM we will try to do up to three links in parallel, and they can take up to ~12-13 GB a piece (most take much less). To some extent we may need to address this through ninja changes that can adaptively change the link parallelism instead of just using floor(GB/5).
,
Apr 11 2016
More details to make sure I can reproduce this later: GYP_DEFINES=branding=Chrome buildtype=Official use_goma=1 gomadir='C:\b\build\goma' fastbuild=1 target_arch=ia32
,
Apr 15 2016
I did a test release build with the GYP_DEFINES listed above and monitored linker working sets to see if I could see anything extreme. The largest linker working set that I noticed was 5825.996 MiB for unit_tests.exe, and only three linker working sets went over 5 GB, so it's hard to see how this problem could be caused by running out of memory. The maximum working set when linking performance_browser_tests.exe was 4275.234. Getting more RAM is still a good idea, and maybe it will resolve this issue - I really can't tell though.
,
Apr 20 2016
Issue 601611 has been merged into this issue.
,
Feb 3 2017
,
Feb 6 2017
This is an old-ish auto-bisect bugs. This might be fixed with Pinpoint, or it's not going to get fixed. If you disagree with me, please reopen the bug and mark it "Untriaged". |
|||
►
Sign in to add a comment |
|||
Comment 1 by dtu@chromium.org
, Apr 8 2016