Phoenix 1.6 using Docker containers ends with segmentation fault / error 139

I’ve compiled as much info as possible in a gist here - but the recap is:

  • it’s a totally “empty” mix phx.new . --app battery_rehab
  • docker compose build works
  • docker compose run --rm phoenix mix test works
  • docker compose up ends phoenix with error 139

I’ve tried to google for it - but somehow I’ve managed to land both feet right into unchartered territory (with the closest thing that I could muster was that rebuild assets.deploy fail) :slightly_frowning_face: which probably speaks to the utter n00bness of me at all dabbling with 1.6 and containers (coming from ruby-land - and been wanting to for nearly 4/5 years on now without getting that well-deserved breakthrough - it’s tough) :cry:

Hoping one of you guys in here knows what kind of animal a ‘139’ is -

BR
Walther

3 Likes

what computer are you on?

looks like esbuild is getting arm64 linux, and then crashing - is that correct-ish?

1 Like

I’m on an M1 (Apple) - and I won’t deny that it sat with me for nearly 8 months before I tried to do any good with it :biohazard: (mostly because things like brew turned out to be such a hazzle :slightly_frowning_face: )

but the container is running off of elixir:latest (the Dockerfile gives that away in line 1) but what “platform” has never been of much interest to me - I use it very frequently with Rails containers

but I have to hurry to admit that I probably should care! And not knowing how to tell Docker to use a different “platform” may be an issue -

by the looks of it - the “platform” is aarch64

root@e2982d09dc8b:/app# uname -a
Linux e2982d09dc8b 5.10.25-linuxkit #1 SMP PREEMPT Tue Mar 23 09:24:45 UTC 2021 aarch64 GNU/Linux

dug into the ‘container-chain’ and it turns out that it all comes down to a Debian of sorts

most likely something with arm64 and that image… can you try using the hexpm/elixir image instead Docker Hub

hexpm/elixir:1.12.0-erlang-24.1-alpine-3.14.0 maybe?

5 Likes

love to - right at it now!

1 Like

thx!

That had me going forward!

Important lesson too! Not all platforms are made equal :wink:

(not that I didn’t know that - from building on Symbian60 in the late '90’s - but I kind’a guessed that with Docker being an “abstraction layer” this sort of was a thing of the past) - guess not :smile:

huge thank you!

2 Likes

awesome!

using https://asdf-vm.com for elixir/erlang/node and just running natively no containers is pretty big here in elixir land, so you can try that some adventurous day :wink:

2 Likes

I’m a big fan of asdf for sure - it did very well in ruby-land too, allowing me to context switch between 10+ year old projects and newly minted ones in a blink of an eye - or should I say cd :laughing:

Maybe the communities around projects like nokogiri have it ironed out by now but going 10/12 months back the M1 platform was in fact a terrible place to be running anything native that would require compiling open source stuff hence the “acquired taste” for containers :wink:

1 Like

Just wanted to say thanks for posting this thread. I hit the exact same error. I thought for sure it would be some obscure thing I’d have to Google for a while. But, nope, the question and answer were right there on the front page of Elixir Forum! :grin:

7 Likes

:mechanical_arm: to outlog - he’s the real hero in this terrible ordeal :smiley:

3 Likes

Docker is only a set of restrictions in terms of system calls, process visibility, filesystem access and networking. There is no hypervisor or virtual CPU.

@binarytemple being inspired by the reboot of The Matrix - or what’s your play?

:laughing:

I’m also on a Mac M1, and running in container to bypass the non-availability of M1 builds of a lot of OSS.

I seem to be running into a similar issue with Phoenix 1.6.4 with a freshly minted app. I tried using

FROM hexpm/elixir:1.13.0-erlang-24.1.7-ubuntu-focal-20210325

If I run esbuild natively, it works. If I run esbuild in container, it segfaults. esbuild seems to be using esbuild-darwin-arm64 natively, but esbuild-linux-arm64 in container. Not sure if this is the root cause.

When I run mix phx.server, it just seems to hang. I never get the “[info] Running Crypto.Endpoint with cowboy 2.9.0 at 0.0.0.0:4000 (http)” output.

I have a feeling this is being caused by esbuild (maybe the watchers), but don’t know how to confirm that.

I’m an erlang/elixir noob, but otherwise pretty experienced. I’m not sure how to go about finding the point at which such a crash might be happening (if it is). Any pointers to the process of diagnosis would be just as helpful as an actual answer. I’m happy to get my hands dirty with low level detail on elixir/erlang/otp.

I tried the following native

Elixir: 1.12.3
Erlang: 24.1
phx_new: 1.6.4

I created a new phoenix project with no db and no mailer.

mix phx.new . --app crypto --no-ecto --no-mailer
mix phx.server

I get the same hanging behaviour that I do in container. The difference is that

mix assets.deploy

works natively, but segfaults in container

So maybe this is an issue with the M1 rather than containerization

How would I go about finding out why/where it’s hanging. Is there a way to log events on the request path? or attach a debugger? some other tool that I’m unaware of?

Looks like part of the problem was with the app name. I guess “crypto” is an existing name somewhere. I changed the app name and it’s running natively now.

In container, I still get a segfault, but now I get the output

“[info] Running MyAppWeb.Endpoint with cowboy 2.9.0 at 127.0.0.1:4000 (http)” output.

so at least it’s getting further. My guess is it’s still something to do with esbuild, darwin vs linux.

Any pointers on how to diagnose would be useful.

I got it running in container by commenting out the esbuild watcher

  watchers: [
    # Start the esbuild watcher by calling Esbuild.install_and_run(:default, args)
#    esbuild: {Esbuild, :install_and_run, [:default, ~w(--sourcemap=inline --watch)]}
  ]

Raised an issue on the repo

It turns out phx.new was generating an older version of esbuild (0.13.5). The new version 0.14.0 appears to be working correctly in container. It’s also the default version used in the current version of the phoenix esbuild installer.

PR submitted.

2 Likes

PR merged.

1 Like