Observer crashed, then server crashed. macOS specific Bug?

I managed to crash :observer, which ended up crashing my development server. I’m not sure where to report this. Please direct me to the correct location. In any case, here’s what I did:

  1. on macOS Sierra, startup phoenix (e.g., Rumbl app) using iex -S mix phoenix.server
  2. run :observer.start
  3. click on Applications tab and navigate to your app name. Mine is Rumbl.
  4. make observer fullscreen.
  5. go to the following child process: Elixir.Rumbl.Endpoint > Elixir.Rumbl.Endpoint.Server > pid# > pid# > pid#
  6. double click on that pid to open it in a new tab.
  7. click on X to close that tab.
  8. the tab still remains. now click on the X again.
  9. erlang crashed.




'iex -S mix phoenix.server' terminated by signal SIGSEGV (Address boundary error)

Been having this too. I managed to recreate this just by steps 1, 2, 3, double click on any process–step 6 (I’ve tried on my Elixir.MyApp.Endpoint.Config), 7, 8, 9. Basically what you did without fullscreen and specific process.

The output of my terminal:

Erlang/OTP 19 [erts-8.2] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

[info] Running MyApp.Endpoint with Cowboy using http://localhost:4000
Interactive Elixir (1.3.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> :observer.start
:ok
iex(2)> [1]    62019 segmentation fault  iex -S mix phoenix.server

Funny thing is, I find that the trigger is doing step 7 and 8 consecutively. The solution (?) is: after you click on X, with the tab still there, lose focus of the Observer window (by clicking on other parts of your desktop, another app’s window, or just via Cmd+Tab switch tabs). It’ll disappear after. Just don’t click the close button twice.

That’s how I ran into it as well (repeatedly clicking on the X button)

I can even reproduce it with Erlang shell

$ erl
Erlang/OTP 19 [erts-8.2] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Eshell V8.2  (abort with ^G)
1> observer:start().
ok
2> [1]    62937 segmentation fault  erl

with the same steps (go to “Applications” tab, double-click any process, click close button, click close button again).

I think this should go to https://bugs.erlang.org but it’s kind of too involved to post issues I don’t know where to start :sweat_smile:.

P.S. I’m using El Capitan.

observer crashes for me quite frequently, Arch Linux, different versions of Erlang. I think it’s simply buggy.

It’s the NIF interface to the underlying wx graphic libraries. This is exactly why NIF’s can be dangerous.

Make sure you’ve run brew update to get the latest libraries. Once I did that things became more stable.

Not a solution to your problem but I found it useful to prevent crashing an important node when Observer occasionally crashes is to run it on a different node.

To accomplish that you need to start your server node in distributed mode. For example by iex --sname my@localhost --cookie my -S mix phoenix.server and start another node by iex --sname observer@localhost --cookie my where you launch observer and use the Nodes menuitem on the GUI to connect to your server node (my@localhost). Make sure both nodes use the same cookie. Observer might still crash but it will not crash your server node.

This method is also the production safe way of using Observer.

5 Likes

thanks! that’s good advice.

Oh, there is one thing I forgot to mention. There are alternatives. https://github.com/zhongwencool/observer_cli is observer, reimplemented not to use GUI.

From my experience, observer crashes when there is a UI bug like when you click around, resize it etc.

The CLI version is extra dependency, yeah, but on the oher hand it works great over SSH. X11 over SSH is quite painful.

4 Likes

observer_cli looks awesome, thanks! Gotta try that soon.

An update for 2020: most folks having Phoenix apps probably want to use Phoenix LiveDahshboard https://github.com/phoenixframework/phoenix_live_dashboard instead