NtCreateFile: Too many open. (Was: Missing TLBREF.dll and warning about "System.Text.Json.JsonEncodedText") #153
Comments
|
CC @ravenexp wrt msbuild Can you reproduce the issue with |
|
Yes, and I've double-checked again now to be sure. Neither of the two commands below work. They don't seem to do anything, and never finishes:
But if I remove the last ".cpp" file in any of these two commands, so that only one .cpp file is compiled, it seems to work. |
|
I cannot reproduce this issue with msbuild. I made a new clean install of msbuild /p:Platform=Win32 /p:PlatformToolset=v143for this project: https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/WinhttpProxy I've checked that ClCompile:
z:\opt\msvc\vc\tools\msvc\14.42.34433\bin\HostX64\x86\CL.exe /c /ZI /JMC /nologo /W4 /WX /di
agnostics:column /Od /Oy- /D WIN32 /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /
RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"WinhttpP.2C0E27FE\Debug\\"
/Fd"WinhttpP.2C0E27FE\Debug\vc143.pdb" /external:W4 /Gd /TP /analyze- /FC /errorReport:queu
e GetProxy.cpp WinhttpProxySample.cpp
GetProxy.cpp
WinhttpProxySample.cpp
Generating Code...The build was successful. |
|
Regarding running directly with wine - the For the example with the |
|
Yes, I'll try to minimize. Also, running "msbuild /p:Platform=Win32 /p:PlatformToolset=v143 cpp/WinhttpProxySample.sln" succeeded, and all the test scripts in the "test" directory works as well. |
|
This was hard. The problem seems to be caused by a combination of flags, and I had to go back and forth adding back commands that seemingly didn't cause the problem. I'm not sure if you can reproduce this, but I've come up with the following: a.cpp: b.cpp: And then in a bash terminal, I run the following: And this is the output (cl never finished): |
|
The "/Zi" and "/external:W3" options I'm not too sure about. At least "/external:W3" I wouldn't be surprised is unrelated. But the "/MP" option is a surely related to the problem somehow. You have to go back and forth and try out combinations and order of combinations. |
|
And by order of combinations, I don't mean that there's a difference between e.g. "/Zi /MP" and "/MP /Zi", although that might be the case also, I haven't checked, but I mean that it might work to first only use the "/MP" option, but the next time it fails, and when you add back the "/Zi" option it works, but the next time it fails again. However the sure thing seems to be that it always fails with both "/Zi" and "/MP", and possibly "/external:W3". It seems like there is a state remembered between each time cl is run. |
|
When I run this line: I get a lot of lines printed out that ends with this: So it's probably some kind of deadlock. |
|
Ok, I think I found the reason, but it's a bit sketchy. Firstly I ran However, 'man systemd.exec` says the following: which explains why it's 100% impossible on Fedora, (looks like), to increase the default value above 1024 except running "ulimit -n". So this doesn't seem like the perfect solution. I guess there could be some bug somewhere in wine that's creating too many file descriptors? |
|
Thanks for the reduced testcase! For some reason, I'm not running into this issue either. (Normally I run with a persistent wineserver which is started with a raised |
|
Actually, nevermind, I did manage to reproduce it when executing with the default |
|
Looks like it doesn't related to export WINEDEBUG=-all
export WINE_MSVC_STDOUT=wine.log.stdout
export WINE_MSVC_STDERR=wine.log.stderr
export BINDIR=/opt/msvc/VC/Tools/MSVC/14.42.34226/bin/Hostx64/x64/
touch {1..16}.cpp
for i in {1..10}; do
echo $i
wineserver -k
wine /opt/msvc/bin/msvctricks.exe ${BINDIR}cl.exe /c /Zi /MP8 {1..16}.cpp
lsof +c0 wine.log.* 2>/dev/null | grep wine
doneThe output looks like below. I don't think the behaviour is correct, a background process should not inherit stdout from its parent. Not sure it is the actuall behaviour of |
Tested on Windows and checked with Process Explorer, From the output above, sometimes stdout get opened multiple times, if I decrease the |
kmatheussen
changed the title
Hi,
After setting up msvc-wine msbuild fails with an error message that it couldn't launch "c1xx.dll". I tracked this error down to a missing TLBREF.dll file. After copying the TLBREF.dll file from my windows computer into directory of "c1xx.dll", I get this warning:
...and the build just stops. The last call to CL.exe just runs forever without using any CPU. The reason for this seems to be that CL.exe is given more than one source file, which I guess is not normal. E.g. like this: "CL.exe a.cpp b.cpp c.cpp d.cpp" (not the actual line, it's just to illustrate.
If I run the CL.exe command that fails one by one, one source at a time, things work. But there's thousands of files in my project and I can't do this manually every time.
So my theory is that at least two of these three mysterious things are connected: 1. the missing TLBREF.dll file, 2 The warning about "System.Text.Json.JsonEncodedText", and 3. more than one source file given as argument to CL.exe.
I've googled the System.Text warning, and it seems to be a common problem, but no clear solution. My theory is that msbuild is reading json files the wrong way and that's why wrong arguments are given to CL.exe.
Anyhow, any ideas what to do?
The text was updated successfully, but these errors were encountered: