Segmentation Fault from within container when trying to run packaged UE4 project

[Kingcitaldo125]

There is an issue, which may or may not be relevant to the ue4-runtime context but I'll post this as an issue in the case that it is, where a docker container will fail to run a shell script that was generated via packaging a UE4 project for Linux and will quickly crash(Segmentation Fault) to the container's shell with limited output.

The context here is a UE4 project that attempts to read images from a folder in the working directory, uses those images to set itself up accordingly, and then tries to output related images back to the disk in a separate directory. I've noticed that turning off the image outputting feature before packaging for Linux bypasses this issue. I wanted to get a second set of eyes on this and possibly some suggestions in regards to fixing this issue and avoiding it in future cases.

Attached is an image of my PuTTY shell that I'm using to get into the container. 'png' is the directory being read from and 'imageoutput' is the directory being written to. If more context is needed for this issue, don't hesitate to ask. I'll try to provide as much info as I can.

Currently trying with '16.04-cudagl10.2-virtualgl' image tag. Seeing the display window in our case is not important at the moment.

Thanks, and please advise,

Paul A

[adamrehn]

The lack of output there is because the project has been packaged in the Shipping configuration. If you package it in the Development configuration (e.g. using ue4 package Development if you're packaging it through ue4cli) then you should see some log output to indicate what error is actually leading to the segmentation fault. That should help provide some clues as to exactly what operation is failing and how, which can then be used to help diagnose the underlying configuration issue.

[Kingcitaldo125]

Thanks for the information. It turns out that our partner's code is trying to access some threading mechanisms that are probably not available within the container (pthread/libpthread). If we needed to access this library, what would be the best way to go about exposing that to the program? I'm assuming that it is possible to either include binaries like that within a package or make them available via some sort of copy-paste instruction(s). I'm also packaging for Linux using the Unreal Editor running on Windows.

Thanks,

Paul A

[adamrehn]

The pthread library is already present in the container (as evidenced by the presence of libpthread.so.0 in the callstack) and should in theory work just fine, although that callstack is a bit concerning. Could you please post the full log output? There's a lot of information that the Unreal Engine prints during initialisation that could help provide some additional clues.

[Kingcitaldo125]

Apologies for the size of the file ahead of time; it's quite large. It does appear that there are permission issues when trying to open up files for writing.

mylog.txt

[adamrehn]

Yeah, I suspect those errno=13 (Permission denied) errors might be the real culprit here. Could you please post your Dockerfile so I can see how you're creating (or copying) the imageoutput directory? It should be a simple fix to set the right permissions, but the means of doing so will vary depending on whether it's being copied from the host with a COPY directive or being created using a RUN directive.

[Kingcitaldo125]

Here's the Dockerfile. I was using 'RUN mkdir imageoutput' to create that folder. Permission errors always seem to be a thorn in my side..

Dockerfile.txt

[adamrehn]

Yep, as I suspected, the directory is owned by the root user because you've created it using a command that's running as root. To fix it, change these lines:

USER root

RUN mkdir imageoutput

USER ue4

To this:

USER ue4

RUN mkdir imageoutput

[Kingcitaldo125]

Yes, that appears to do the trick. It looks like the tool is able to save images to that directory now. It's funny and frustrating how some complicated errors can be so simple to fix.

Thanks so much for your help resolving this.

Paul A