Description
I reproduced this with latest luvi (v2.12.0) on both alpine and ubuntu docker environments with both building from source and using the prebuilt get-lit luvi binaries. I don't think it's a luvi issue entirely.
A simple docker based luvi+lit app looks something like this:
FROM creationix/lit
ADD package.lua .
RUN lit install
ADD main.lua .
EXPOSE 8080
CMD ["luvi", "."]
This normally works great, but with the latest version of lit, it will fail after lit install
finishes:
$ docker build webserver/
Sending build context to Docker daemon 4.096kB
Step 1/6 : FROM creationix/lit
---> 59a1da203be1
Step 2/6 : ADD package.lua .
---> e22d625ce600
Step 3/6 : RUN lit install
---> Running in f58a663faf85
lit version: 3.8.5
luvi version: v2.12.0
command: install
create config: /root/.litconfig
connecting: wss://lit.luvit.io/
fetching: 1 object
...
fetching: 1 object
including dependency: coro-channel (3.0.3)
...
including dependency: weblit-server (3.1.3)
installing package: creationix/[email protected]
...
installing package: luvit/[email protected]
done: success
The command '/bin/sh -c lit install' returned a non-zero code: 139
I'm wondering if it's related to some recent changes to how stdout is managed in pretty-print? Not sure really.
I can work around the issue in the Dockerfile
by ignoring the return value like RUN lit install || true
. As far as I can tell, the result is correct.
I don't think it's related to a lack of tty. I can use docker run creationix/lit lit ...
with or without a pseudo terminal and there are no segfaults for any lit command. All lit commands segfault while exiting during the docker build step.