Crashes if I resize the window

[haf]

Environment: OS X, iTerm, zsh

Unhandled Exception:
fszmq.ZMQError: No such file or directory
  at fszmq.SocketModule.TryRecv (fszmq.Socket socket, Int32 length, Int32 flags) <0x109e14440 + 0x001c2> in <filename unknown>:0
  at Logary.Services.Rutta+Router+outer@287-2T[b].Invoke (Microsoft.FSharp.Core.Unit unitVar0) [0x0000a] in /Users/h/dev/haf/logary/src/services/Logary.Services.Rutta/Rutta.fs:290
[ERROR] FATAL UNHANDLED EXCEPTION: fszmq.ZMQError: No such file or directory
  at fszmq.SocketModule.TryRecv (fszmq.Socket socket, Int32 length, Int32 flags) <0x109e14440 + 0x001c2> in <filename unknown>:0
  at Logary.Services.Rutta+Router+outer@287-2T[b].Invoke (Microsoft.FSharp.Core.Unit unitVar0) [0x0000a] in /Users/h/dev/haf/logary/src/services/Logary.Services.Rutta/Rutta.fs:290

Repro code: causiq/logary@16cda96

Repro cmd: mono --debug bin/Debug/rutta.exe --router tcp://127.0.0.1:6111 --router-target influxdb://user:pass@host:8086/write?db=databaseName --health 127.0.0.1 8889 from src/services/Logary.Services.Rutta.

[pblasucci]

hmmm... This is odd. I will have a go a reproducing later tonight (I'm not near a dev machine, at the moment). But, based of a cursory glance, I see that you're carrying disposable state on an F# record. I've never had any luck with getting record types to properly implement IDisposable. So, I'm not suggestion that's the issue... but it's certainly something that has burned me in the past.

At any rate, I'll investigate as soon as I can. Thanks.

[pblasucci]

@haf So I was unable to compile the code (some weirdness with rake). But I looked at it more closely anyway. It seems the line in question only partially applies the call to Socket.tryRecv. I suspect this could be the problem. Maybe you meant Socket.recv? Also, is there any way you could create a simpler repro? Or possibly make a binary available? Otherwise, I'm left with simply offering suggestions based on reading a dead listing. Thanks!

[haf]

I think the problem is that ZeroMQ subscribes to a number of signals from the shell and the resize operation is one of those signals. The docs of ZMQ states that if you pass SIGINT to a process that is blocking in ZMQ recv, it will yield and return null from the call. However, in this case, we're not passing SIGINT, but another interrupt code. Perhaps ZeroMQ tries to load libsodium or some other dependency like PGM at this point, and fails causing the above exception.

I would love it if you could tell me what command you ran when you tried to build and what error message you received?

[pblasucci]

Hmmm... you might be right about the signal being misinterpreted. Dealing with signal differences is one of the thornier bits in wrapping cross-platform code.

As for the code errors, when I try to build the solution in Xamarin Studio, it fails because I'm missing several dependencies. However, whenever I try to execute any Rake tasks, I get:

rake aborted!
cannot load such file -- bundler/setup

[haf]

Run:

gem install bundler
bundle exec rake

And it should work just fine

[pblasucci]

No luck. I needed to run bundle install, but it failed on nokogiri. So I try to install nokogiri via gem and it failed to compile some of the native portions of the library.

At this point, if you truly suspect the issue is with signalling, perhaps you can make a simpler repro?

[haf]

I will, come Monday. But the short answer is to create a pull socket in a .Net 4.5 console app and resize in iTerm/zsh (oh-my-zsh to be exact).

Thank you for looking into this for me. I really appreciate the support =)

[pblasucci]

This behavior is 100% reproducible using OS X's defaults (Terminal running bash). It will take time to investigate further. But as of right now, is looks like an issue inside of libzmq.dylib. For what it's worth, spawning it as a background process (unsurprisingly) negates the issue. When I have a minute, I'll make an inquiry on the mailing list.

Thanks for bringing this to my attention.

[pblasucci]

Just a quick update. I'm not getting the actual error you reported (my bad for not realizing sooner). However, I am getting an EINTR when I resize the terminal window. So something is definitely screwy with the signalling (aside: I suspect the difference in error message is due to bash vs zsh).

Anyway, after doing a bit of experimentation and research, I've determined it's NOT an issue with libzmq. It seems to be related to a know issue with Mono on POSIX-compatible OSes (based on a bunch of searching starting from here: http://lists.zeromq.org/pipermail/zeromq-dev/2011-March/009853.html). Unfortunately, I don't have a good "fix" for this at the moment. But I plan to investigate this further.

I will keep you posted, but I'm not optimistic for an easy solution.

[pblasucci]

I've been unable to make any progress on this. I'm going to unassign myself in the hopes that someone smarter than me can be of help

[pblasucci]

So, I've made an interesting discovery relative to this issue. First, it definitely still exists (thanks, mono). However, it does appear to be constrained to running sockets on the primary thread. Simply moving things to an async workflow (or even TPL or -- gasp! -- a new Thread) makes the issue go away. While this is not ideal, it is a reasonable work-around. So I'm going to close this issue. But make a note to document this in #144.