has anyone else seen Erlang 19 break 'bash' after exit?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

has anyone else seen Erlang 19 break 'bash' after exit?

Matthias Lang
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: has anyone else seen Erlang 19 break 'bash' after exit?

Igor Clark
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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: has anyone else seen Erlang 19 break 'bash' after exit?

Lukas Larsson-8
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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: has anyone else seen Erlang 19 break 'bash' after exit?

Igor Clark
Hi Lukas, I just tried with erlang R17 to check, and it seems to work fine with the newer homebrew version of bash as well as the older default /bin/bash. So maybe this helps confirm your suspicion.

best,
Igor

On 14/03/2017 15:40, 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: has anyone else seen Erlang 19 break 'bash' after exit?

Matthias Lang
In reply to this post by Lukas Larsson-8
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 <[hidden email]> 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
> >> [hidden email]
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >>
> >
> > _______________________________________________
> > erlang-questions mailing list
> > [hidden email]
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions