New issue
Advanced search Search tips

Issue 668961 link

Starred by 4 users
Status: WontFix
Owner: ----
Closed: Mar 2017
Cc:
hlundin@chromium.org
thakis@chromium.org
oprypin@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Win 64-bit Debug linking error: "fatal error LNK1235: corrupt or invalid COFF symbol table"

Project Member Reported by kjellander@chromium.org, Nov 28 2016 
We've seen at least one error of compilation failing with 

[3447/3665] LINK rtp_analyze.exe rtp_analyze.exe.pdb
FAILED: rtp_analyze.exe rtp_analyze.exe.pdb 
E:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./rtp_analyze.exe /PDB:./rtp_analyze.exe.pdb @./rtp_analyze.exe.rsp
webrtc_common.lib(config.obj) : fatal error LNK1235: corrupt or invalid COFF symbol table


Example trybot:
https://build.chromium.org/p/tryserver.webrtc/builders/win_x64_clang_dbg/builds/7625/steps/compile/logs/stdio
which comes from https://codereview.webrtc.org/2533543002/ that includes rolling Clang 284979 -> 28778 (https://chromium.googlesource.com/chromium/src/+/5e821a778b..5c22c2afac/tools/clang/scripts/update.py)


Another linking error also happens (flakily) on the same binary (rtp_analyze.exe) for the non-Clang trybot:

[3390/3665] LINK rtp_analyze.exe rtp_analyze.exe.pdb
FAILED: rtp_analyze.exe rtp_analyze.exe.pdb 
E:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./rtp_analyze.exe /PDB:./rtp_analyze.exe.pdb @./rtp_analyze.exe.rsp

  Version 14.00.24213.1

  ExceptionCode            = C0000005
  ExceptionFlags           = 00000000
  ExceptionAddress         = 000000013FFD52DC (000000013FFC0000) "E:\b\depot_tools\win_toolchain\vs_files\d5dc33b15d1b2c086f2f6632e2fd15882f80dbd3\win_sdk\bin\..\..\VC\bin\amd64\link.exe"
  NumberParameters         = 00000002
  ExceptionInformation[ 0] = 0000000000000000
  ExceptionInformation[ 1] = 0000000500000010

CONTEXT:
  Rax    = 0000000500000000  R8     = 00000002010FEC00
  Rbx    = 0000000201398708  R9     = 00000002010FECB0
  Rcx    = 0000000000299800  R10    = 0000000140094748
  Rdx    = 00000002010FEF60  R11    = 00000000000001DB
  Rsp    = 000000000016ECD0  R12    = 00000002010FECB0
  Rbp    = 000000000016ED30  E13    = 0000000000000000
  Rsi    = 0000000002356B50  R14    = 0000000200400000
  Rdi    = 0000000000000000  R15    = 00000002010FECB0
  Rip    = 000000013FFD52DC  EFlags = 0000000000010246
  SegCs  = 0000000000000033  SegDs  = 000000000000002B
  SegSs  = 000000000000002B  SegEs  = 000000000000002B
  SegFs  = 0000000000000053  SegGs  = 000000000000002B
  Dr0    = 0000000000000000  Dr3    = 0000000000000000
  Dr1    = 0000000000000000  Dr6    = 0000000000000000
  Dr2    = 0000000000000000  Dr7    = 0000000000000000

https://build.chromium.org/p/tryserver.webrtc/builders/win_x64_dbg/builds/3572/steps/compile/logs/stdio


hlundin: is there anything odd going on with this binary that could explain this?

Comment 1 by ehmaldonado@chromium.org, Nov 28 2016 

It fails consistently in the Win8 and Win10 bots in the FYI waterfall.

Comment 2 by kjellander@chromium.org, Nov 28 2016 

For Win8 it was another error: "fatal error LNK1106: invalid file or disk full: cannot seek to 0x482BBCAB" which is covered in bug 615050.
Example: https://build.chromium.org/p/client.webrtc.fyi/builders/Win64%20Debug%20%28Win8%29/builds/279/steps/compile/logs/stdio
It just went green again with a new roll though: https://build.chromium.org/p/client.webrtc.fyi/builders/Win64%20Debug%20%28Win8%29/builds/280

Our Win10 bot still fails with this error: https://build.chromium.org/p/client.webrtc.fyi/builders/Win64%20Debug%20%28Win10%29

Comment 3 by ossu@chromium.org, Nov 28 2016 

Looking through the latest handful of Win64 Debug compilations, successes and failures, seem to indicate that compilation works fine on the following slaves:
- vm162-m3
- vm193-m3

and fails on the following:
- vm87-m3
- vm89-m3
- vm169-m3

It's not a great sample size (9 builds) but a couple of them are used more than once and consistently fail or succeed.

Comment 4 by deadbeef@chromium.org, Nov 29 2016 

Issue 669269 has been merged into this issue.

Comment 5 by ossu@chromium.org, Nov 29 2016 

The last set of errors in my email are from:
- vm87-m3 (once)
- vm89-m3 (three times)
- vm169-m3 (once)

No other VMs were included in the failures.
Is it possible to disable these three until the root cause can be investigated?

Comment 6 by kjellander@chromium.org, Nov 29 2016 

I will submit a landmine CL to ensure all Windows VMs are clobbered when syncing past the landmine. Then if the problem reappears we can look into disabling the VMs.
Project Member

Comment 7 by bugdroid1@chromium.org, Nov 29 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/455b512333ca42446a58af0eaf854419b00c2a81

commit 455b512333ca42446a58af0eaf854419b00c2a81
Author: Henrik Kjellander <kjellander@webrtc.org>
Date: Tue Nov 29 10:14:35 2016

Landmine to clobber Windows builders

Speculative clobber to see if the Win 64-bit Debug linking
errors go away.

BUG= chromium:668961 
TBR=ossu@webrtc.org

Review URL: https://codereview.webrtc.org/2538593003 .

Cr-Commit-Position: refs/heads/master@{#15289}

[modify] https://crrev.com/455b512333ca42446a58af0eaf854419b00c2a81/webrtc/build/get_landmines.py

Comment 8 by ossu@chromium.org, Nov 29 2016 

Clobber seems to have solved the problems for now. A case of invalid, left-over object files perhaps?

Comment 9 by deadbeef@chromium.org, Nov 29 2016 

The clobbering seemed to help for a while. But there have still been two instances of this problem today, on vm88-m3 and vm89-m3.

Comment 10 by kjellander@chromium.org, Mar 27 2017

Status: WontFix (was: Untriaged)
It seems we no longer hit this bug. Reopen if it resurfaces.
►

Sign in to add a comment