[erlang-questions] has anyone else seen Erlang 19 break 'bash' after exit?

[Matthias Lang]

Hi,

With help from my colleague Thomas, I chased the problem I'm seeing.

I am fairly sure that

   - It's a bug in Bash. Already been reported.
   - Affects all versions of Bash from 4.4.0 onwards (current tip 4.4.12)
   - Doesn't affect Bash 4.3.x

I bisected Bash to find the offending commit. On 'master', it's
a0c0a00fc4, but that commit includes 500 changed files and about 200k
insertions + deletions. I could chase some more (there are more
branches and tags), but it seems pointless given that there's a bug report:

  http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00039.html

There's a patch and a "don't hold your breath" comment a few posts later.

Thanks for the confirmations and comments.

Matt

----------------------------------------------------------------------
On 14. March 2017, Lukas Larsson wrote:

> Hello,
>
> I think that it may be a change done in Erlang/OTP 18 that causes this
> behaviour. Specifically OTP-12239. Using non-blocking I/O on stdin/stdout
> seems to kind of work, until it doesn't. Different platforms and tools
> handle it very differently.
>
> The only "solution" that I can think of right now is to use dedicated read
> and/or write threads within the VM to handle stdin/stdout, but I was hoping
> to avoid having to do that.
>
> The problem, for those that are interested, is that the O_NONBLOCK flag is
> set on the file description, not the file descriptor. Which causes all
> kinds of problems, I thought I had handled them all, but apparently not
> enough.
>
> Lukas
>
> On Tue, Mar 14, 2017 at 1:35 PM, Igor Clark <igor.clark@REDACTED> wrote:
>
> > Hello Matthias,
> >
> > Not sure if it's related, but I see bash v4.4.5 terminal I/O get really
> > messed up on Mac OSX after the erlang runtime aborts. It happens whether
> > through a NIF segfault during dev, or just by doing ^C and 'abort'. The
> > terminal input becomes unusable, vim buffers don't display roughly half the
> > text; 'reset' makes no difference, I have to close the Terminal.app window
> > and start over. Haven't had time to dig into it at all, just kind of got
> > used to it.
> >
> > I thought it might be R19, but I switched back to R18 and it still
> > happened. Which made me wonder if it's anything to do with tmux, but I
> > tried it in a standard Terminal window without tmux, and it happened then
> > too. So I tried using the default OSX /bin/bash (which is v3.2.57) instead
> > of the homebrew version (4.4.5) - and it didn't happen at all.
> >
> > Which is a long-winded way of saying, maybe this might also be a "recent
> > bash" issue, rather than an erlang issue?
> >
> > Cheers,
> > Igor
> >
> >
> > On 13/03/2017 20:32, Matthias Lang wrote:
> >
> >> Hi,
> >>
> >> Erlang 19.1 and 19.2 seems to break something to do with terminal
> >> input on some but not all of my Debian x86-64 machines. I took a quick
> >> look through the recent mailing list archives and haven't seen any
> >> mention of this. Maybe I missed it. Maybe it's just me.
> >>
> >> Example:
> >>
> >>     | ~ >uname -a
> >>     | Linux hec 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64
> >> GNU/Linux
> >>     | ~ >read x
> >>     | hello world
> >>     | ~ >erl
> >>     | Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4]
> >> [async-threads:10] [hipe] [kernel-poll:false]
> >>     |
> >>     | Eshell V8.1  (abort with ^G)
> >>     | 1>
> >>     | BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
> >>     |        (v)ersion (k)ill (D)b-tables (d)istribution
> >>     | a
> >>     | ~ >read x
> >>     | bash: read: read error: 0: Resource temporarily unavailable
> >>
> >> The "read error: 0: Resource temporarily unavailable" part is unexpected.
> >> Using 'cat' instead of 'read' produces a similar error:
> >>
> >>     | cat: -: Resource temporarily unavailable
> >>
> >> 'strace' tells me something is screwy about stdin:
> >>
> >>     | read(0, 0x7f1010dbb000, 131072)         = -1 EAGAIN (Resource
> >> temporarily unavailable)
> >>
> >> read(2) tells me EAGAIN suggests that stdin has been left in with
> >> O_NONBLOCK.
> >> Is that Erlang's problem to clean up, or is that supposed to happen on
> >> program exit? I haven't read up on that.
> >>
> >> Doing the same thing on 17.4 works fine.
> >>
> >> Debian 3.16.39-1 and erts-8.2.1 produces a related by different
> >> strangeness:
> >>
> >>     | 1>
> >>     | BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
> >>     |       (v)ersion (k)ill (D)b-tables (d)istribution
> >>     | a
> >>     | $ sh: turning off NDELAY mode
> >>
> >> Can anyone else see this? Any idea what's up?
> >>
> >> Matt
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >>
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >