Closed CanisHelix closed 3 years ago
Repeated and replicated. Attaching full pipe out buid.log
Apparently this is "module not found", and a poke at FOpenCVHelperModule::StartupModule
suggests it failed loading opencv_world331.dll
or one of its dependencies.
The DLL shouldn't have changed between 4.26 and 4.27, but OpenCVHelperModule.cpp
did; in fact, the new code comes into effect on line 91, so perhaps cv::unreal::SetMallocAndFree
is triggering some code in opencv_world331.dll
which tries to on-demand load some other DLL, and it's missing from our container, and hence barfing.
Actually, the relevant change (fabe0dbb438b80de06385ebf36b529bbf36e55f2 in Unreal Engine on GitHub, CL 16620921) did update the opencv_world311.dll
without renaming it, so maybe worth checking the DLL dependency chain for that library in UE 4.26 and UE 4.27 in case we need to add a new DLL to the copied-DLL list.
Offtop: @CanisHelix even if this gets fixed you will want to run ue4-docker with --exclude debug
because of #99. Just saving you another 4 hours on the next run)
@slonopotamus As you can see I used that already, no choice with windows anyway in the original post.
ue4-docker build 4.27.0 --visual-studio=2019 --no-engine --exclude debug --exclude templates --monitor
But, just an update running with --exclude ddc
in addition to the above allows this step to process and finishes all the way to building the ue4-full image.
Oh, sorry, I've inverted true/false
in excluded_components
somehow.
Yeah, --exclude ddc
should be OK as a workaround for now.
I'm not sure that the problem is in 4.26 -> 4.27 move. These deps look identical.
However, ue4-docker-prerequisites is missing avifil32.dll. I wonder if it is a regression or it never had one.
Internets say we might also need:
avicap32.dll
avifil32.dll
msacm32.dll
msvfw32.dll
We're missing avifil32.dll
and msacm32.dll
from this list.
Those are core Windows files, so I can't see how any other variations (Visual Studio, Windows SDK) would have changed their presence.
Another reference concurs that these files are not normally in the Server Core container image (although that's ltsc2016 era).
I'm looking into ue4-build-prerequisites:ltsc2019-vs2019
and it neither has C:\Windows\system32\avifil32.dll
nor C:\Windows\system32\msacm32.dll
.
Hmm. Before #187 we weren't copying any of the V4W (or Media Foundation) DLLs explicitly from the host. So either we never had them, or they were coming from somewhere else implicitly and we were picking up more from that mechanism than the explicit list we have now.
Either way, seems like an easy fix to just add those DLLs to the copy list. They're core components shipped with Windows, so they shouldn't be missing from the host.
Here's what was copied before #187 from host: https://github.com/adamrehn/ue4-docker/pull/187/files#diff-d82b5260e32a8382b1f0fa3045572374766e152bb6063bf6ef9e31bbbeb5baebL35-L44
common = ['dsound.dll', 'opengl32.dll', 'glu32.dll']
return ['ddraw.dll'] + common if basetag == 'ltsc2016' else common
That's my point. avicap32.dll
and msvfw32.dll
aren't in that list either. and supposedly aren't in the servercore image, but we weren't having this problem with 4.26.
I'm currently downloading and older ue4-build-prerequisites
(it is even pre-VS2019 support, built somewhere around commit 6d2a8ee3c44f11126a0815f175b4a0b4d9a40619) to check whether avifil32.dll
/msvfw32.dll
were there...
UPD: they weren't.
It might end in something like "that OpenCVLensDistortion plugin always broken in ue4-docker and we only noticed that now because 4.27 added TP_InCamVFXBP template project that tries to load OpenCVLensDistortion".
The other possibility is that these files have always been missing, but 4.27.0 changed behaviour and crashes when the OpenCV runtime fails to load, where previously, it would error and continue on.
That's probably what happened, looking at a44e2327dcee0645765267963fdd526fcd1bba36 (CL 16620946) in 4.27. The new call to cv::unreal::SetMallocAndFree
in FOpenCVHelperModule::StartupModule
is not protected by a check of OpenCvDllHandle
, and fails if the DLL failed to load. The existing use of that pointer is checked before calling.
cv::unreal::SetMallocAndFree
is implicitly referencing the DLL symbols, so I suspect that inside the container, any use of OpenCV would have had the same issue. This is the line number in the crash, too, so I'm pretty confident that's the reason it's now failing.
So I think this is a bug in that new UE4 code in FOpenCVHelperModule::StartupModule
, but it only replicates if OpenCV fails to load, which might not be a supported scenario since it depends on Windows core components? Maybe worth flicking up to them to resolve for future though.
Blind fix: #198. My Windows build machines are a bit occupied currently, so it will take several days before I can test that it actually fixes the problem.
Thinking about this, the core issue is that the Epic code here is mixing two different styles of DLL usage: They're explicitly loading the DLL and getting the handle pointer, but all their actual OpenCV API access (including the custom cv::unreal::SetMallocAndFree
API that as of 4.27 is being called in StartupModule
) is doing delay-loaded lazy symbol resolution.
It would be less bug-prone if they picked one or the other, either explicitly loading the DLL and using GetProcAddress
to populate function pointers (which would enforce checking the module pointer any of the APIs could be called), or using only delay-loading and correctly implementing the "Failed to delay-load" hook that's currently raising an exception in __delayLoadHelper2
in the absence of a failure hook.
I've just run into this while building 5.0.0-release (right at the end of a 16+ hour build). I'd really like to get a build with DDC, is there any way I can disable either the OpenCV plugin or the sample code that uses it, without having to use --exclude ddc
? 🙏
Are you sure you run into this? This was fixed in #198. Note that there also was edcedca7149272b0620b1cde148edd8a584eca70 (released in ue4-docker 0.0.97), specifically targeted at fixing DDC generation for UE-5.0.
Ah, I missed that commit, thanks for the heads up @slonopotamus! I was using v0.0.96, I'll try with 0.0.97 🤞
Additional details:
Command Used:
ue4-docker build 4.27.0 --visual-studio=2019 --no-engine --exclude debug --exclude templates --monitor
Initial Build Log:
It fails after an overnight build with the final log of
I am re-building now after cleaning all images again with a pipe to build.log so that I can capture a full error log with the verbose option.
I have manually implemented https://github.com/adamrehn/ue4-docker/pull/195 in order to progress this far due previous failure, all images were cleaned after implementing the PR to ensure clean images.