Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

improper PDB files handling by ICC on Windows

sav
Novice
1,663 Views

Hello, everyone,

Found, that ICC handles PDB files in somewhat different way than MSVC do, which could lead to errors during build. E.g. for OpenSSL builds using ICC on Windows got:
1. improper PDB files naming:

[run 'Compiler 17.0 Update 2 for Intel 64 Visual Studio 2015 environment' command && change into OpenSSL sources directory]
c:\libOPENSSL-1.1.1-dev\build>set CC=icl
c:\libOPENSSL-1.1.1-dev\build>perl Configure threads no-deprecated shared no-asm VC-WIN64A && nmake
[snip]
        "C:\ProgramData\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "crypto\include\internal\bn_conf.h.in" > crypto\include\internal\bn_conf.h
        "C:\ProgramData\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "crypto\include\internal\dso_conf.h.in" > crypto\include\internal\dso_conf.h
        "C:\ProgramData\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\openssl\opensslconf.h.in" > include\openssl\opensslconf.h
        icl  /I "." /I "crypto\include" /I "include" -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_API_COMPAT=0x10100000L "-DENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 /Zi /Fdossl_static -c /Focrypto\aes\aes_cbc.obj "crypto\aes\aes_cbc.c"
aes_cbc.c
error #31000: corrupt PDB file ossl_static\vc140.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead
error code 3 ( can't write file, out of disk, etc.) opening pdb ossl_static\vc140.pdb
compilation aborted for crypto\aes\aes_cbc.c (code 1)
NMAKE : fatal error U1077: '"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\bin\intel64\icl.EXE"' : return code '0x1'
Stop.


which relate to compiler keys
'/Fdossl_static', '/Fddso' and '/Fdapp'
in file 'Configurations/10-main.conf' from OpenSSL sources folder.

And if they are changed to
'/Fdossl_static.pdb', '/Fddso.pdb' and '/Fdapp.pdb'
before build, PDB files are created with proper names
'ossl_static.pdb', 'dso.pdb' and 'app.pdb',
and all 'nmake' tasks finishes successfully.

Error not reproduces for builds using MSVC. E.g. ICC, unlike MSVC, require explicitly specify '.pdb' extension of PDB files in '/Fd' keys. Otherwise ICC set PDB file names to '...\vc140.pdb'.


2. improper PDB files handling for parallel builds:
 

[extract 'jom' and 'nasm' executables to OpenSSL directory && run 'Compiler 17.0 Update 2 for Intel 64 Visual Studio 2015 environment' command && change into OpenSSL sources directory]
c:\libOPENSSL-1.1.1-dev\build>set CC=icl
c:\libOPENSSL-1.1.1-dev\build>perl Configure -QxAVX -fp:strict -Qprec -Zc:wchar_t -nologo -Qstd=c11 -O3 -MD threads no-deprecated shared VC-WIN64A && jom /J4
[snip]
        icl  /I "include" -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_API_COMPAT=0x10100000L "-DENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2  -QxAVX -fp:strict -Qprec -Zc:wchar_t -nologo -Qstd=c11 -O3 -MD /Zi /Fdapp.pdb -c /Fotest\buildtest_x509v3.obj "test\buildtest_x509v3.c"
icl: command line warning #10120: overriding '/O2' with '/O3'
buildtest_x509v3.c
        IF EXIST test\shlibloadtest.exe.manifest DEL /F /Q test\shlibloadtest.exe.manifest
error #31000: corrupt PDB file app.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead
error code 3 ( can't write file, out of disk, etc.) opening pdb app.pdb
compilation aborted for test\buildtest_x509.c (code 1)
jom: C:\libOPENSSL-1.1.1-dev\build\Makefile [test\buildtest_x509.obj] Error 1
        link /nologo /debug /subsystem:console /opt:ref /out:test\shlibloadtest.exe @C:\Users\test\AppData\Local\Temp\shlibloadtest.exe.5752.221687.jom
        IF EXIST test\shlibloadtest.exe.manifest  mt -nologo -manifest test\shlibloadtest.exe.manifest -outputresource:test\shlibloadtest.exe
jom: C:\libOPENSSL-1.1.1-dev\build\Makefile [all] Error 2

Error reproduced for Release+Shared configuration if jobs number > 3 (other configurations require more; need be verified). Running 'nmake' or 'jom /J1' command from that point continue build and successfully finishes all tasks.

ICC has no appropriate compiler key for PDB files handling during parallel builds (similar to '/FS' for MSVC). Then assumed, that ICC dealing with this "things" by itself. In such case it turns out, that ICC has limitation on parallel jobs number for single PDB file processing, which MSVC hasn't.

Since ICC on Windows imitates MSVC, is it possible to make its behavior regarding PDB files identical to MSVC for both cases above?

UPDATE: Reproduced 'error #31000: corrupt PDB file' for Boost-1.64 parallel build using ICC with Debug+Shared configuration for Boost.Thread module. Not reproduced, if build made without parallelism.


Environment:

 


Alexander

 

0 Kudos
1 Solution
Judith_W_Intel
Employee
1,663 Views

 

thanks for the report. From a debug developer:

I filed CMPLRS-42592 against DGI for the first issue.

The second issue is an unsupported feature and is documented in CMPLRS-4435..

This is from the description in CMPLRS-4435:

MSPDBSRV.EXE is a service that gets started by VS to handle access to the pdb file.  I believe it has been troublesome in the past when doing parallel builds  (for both MS and us).   If it’s not already running, I think it will get started when we make a call into one of the mspdb dlls.

It’s purely a guess on my part, but perhaps they have developed a replacement for MSPDBSRV.EXE that is the new default and the /FS switch forces the old behavior.  We’ll want to look at this and possibly support this switch.

View solution in original post

0 Kudos
6 Replies
Judith_W_Intel
Employee
1,664 Views

 

thanks for the report. From a debug developer:

I filed CMPLRS-42592 against DGI for the first issue.

The second issue is an unsupported feature and is documented in CMPLRS-4435..

This is from the description in CMPLRS-4435:

MSPDBSRV.EXE is a service that gets started by VS to handle access to the pdb file.  I believe it has been troublesome in the past when doing parallel builds  (for both MS and us).   If it’s not already running, I think it will get started when we make a call into one of the mspdb dlls.

It’s purely a guess on my part, but perhaps they have developed a replacement for MSPDBSRV.EXE that is the new default and the /FS switch forces the old behavior.  We’ll want to look at this and possibly support this switch.
0 Kudos
sav
Novice
1,663 Views

Thank you for a quick response. It will be convenient to get this functionality, or at least part of it, in future ICC versions.

 

Alexander

 

0 Kudos
Stephen_M_Intel
Employee
1,663 Views

With regards to the second issue, adding support for the "/FS" option in ICC unfortunately would not resolve this error.  The description of the "/FS" option includes the following text:

     "The /FS compiler option prevents the compiler from locking the PDB file and forces writes to go through MSPDBSRV.EXE, which serializes access."
 
The "/FS" option was added in VS2013 because the default behavior of MSVC was changed to avoid using MSPDBSRV.EXE in an attempt to reduce compile time.  Prior to VS2013, writes to the pdb file always went through MSPDBSRV.EXE.

Forcing writes of the PDB file to go though MSPDBSRV.EXE is actually the only method ICC supports, i.e. the "/FS" behavior is always enabled with ICC when using /Zi.

The other option for writing debug info, /Z7, will cause the compilers to write all the debug info (not just some) into the object files.  The pdb file will then get generated at link time.  The downside to this approach is it will increase object file size and link time.

-Steve

0 Kudos
sav
Novice
1,663 Views

Just tested OpenSSL parallel build using MSVC _without_ '-FS' key and got error:

	cl  /I "." /I "crypto\include" /I "include" /I "c:\libOPENSSL-1.1.1-dev\build\..\..\libZLIB-1.2.11\MSVC64RH\include" -DZLIB -DZLIB_SHARED -D"LIBZ=\"ZLIB1\"" -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSL_API_COMPAT=0x10100000L -DWIN32 -D_WIN32 -DWIN64 -D_WIN64 -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE -DNDEBUG -D_NDEBUG "-DENGINESDIR=\"C:\\libOPENSSL-1.1.1-dev\\MSVC64RH\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\libOPENSSL-1.1.1-dev\\build\\..\\MSVC64RH\\ssl\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2  -arch:AVX -fp:strict -Zc:wchar_t -nologo -O2 -MD /Zi /Fdossl_static -c /Focrypto\aes\aes_ige.obj "crypto\aes\aes_ige.c"
aes_ige.c
crypto\aes\aes_ige.c: fatal error C1041: cannot open program database 'c:\libOPENSSL-1.1.1-dev\build\ossl_static.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS

which is pretty similar to ICC error from second issue:

error #31000: corrupt PDB file app.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead
error code 3 ( can't write file, out of disk, etc.) opening pdb app.pdb

E.g. both errors relate to inability "write to (the same .PDB) file". And MSVC parallel build error not reproduced, if '-FS' option is used. Thus I assume '-FS' option relate to this issue.

 

Alexander

 

0 Kudos
sav
Novice
1,663 Views

Any news on this? CMPLRS-42592 reproduced in IPSXE 2018 Update 3:

c:\test>echo void foo(){}; > test.c && icl -nologo -c test.c -Fdtest && echo SUCCEDED || echo FAILED

test.c
SUCCEDED

c:\test>echo void foo(){}; > test.c && icl -nologo -c test.c -Zi -Fdtest && echo SUCCEDED || echo FAILED

test.c
error #31000: corrupt PDB file test\vc140.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead
error code 3 ( can't write file, out of disk, etc.) opening pdb test\vc140.pdb
compilation aborted for test.c (code 1)
FAILED

c:\test>echo void foo(){}; > test.c && icl -nologo -c test.c -Zi -Fdtest.pdb && echo SUCCEDED || echo FAILED

test.c
SUCCEDED

while was expected to be fixed in IPSXE 2018 Update 2.

 

Alexander

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,663 Views

I've had issues on Windows builds with "failure to write to ...pdb" being caused by the Anti-Virus software having a file lock on the file. To correct for this, set an exclusion for the output folder.

Jim Dempsey

0 Kudos
Reply