[erlang-questions] Erlang initiated kernel panic on OSX

[Alexander Zhuravlev]

On Mon, Nov 26, 2012 at 04:02:40PM -0500, acidbriggs@REDACTED wrote:
> Don't get me wrong, I have no doubts that it's an OS X bug. But, getting that fixed via Apple is next to impossible. I am not sure of the mechanism as to why it crashes the OS, but it does. It is reproducible. I was just hoping someone might know how to patch Erlang to help avoid the OS X bug as it's really irritating.
> 
> If anyone is curious you can see that the process that caused the panic was named "beam.smp":
> 
> Interval Since Last Panic Report:  2399141 sec
> Panics Since Last Report:          1
> Anonymous UUID:                    1C24E5B9-05B7-8082-2863-4E5C3ECA6AEC
> 
> Thu Nov 15 11:44:13 2012
> panic(cpu 2 caller 0xffffff8006d1fdca): "negative open count (c, 16, 3)"@/SourceCache/xnu/xnu-2050.18.24/bsd/miscfs/specfs/spec_vnops.c:1813
> Backtrace (CPU 2), Frame : Return Address
> 0xffffff80f7e1bbe0 : 0xffffff8006c1d626 
> 0xffffff80f7e1bc50 : 0xffffff8006d1fdca 
> 0xffffff80f7e1bc90 : 0xffffff8006d24c56 
> 0xffffff80f7e1bce0 : 0xffffff8006d11c96 
> 0xffffff80f7e1bd20 : 0xffffff8006d094af 
> 0xffffff80f7e1bd50 : 0xffffff8006d08645 
> 0xffffff80f7e1bda0 : 0xffffff8006f4c56c 
> 0xffffff80f7e1be10 : 0xffffff8006f4cae6 
> 0xffffff80f7e1be50 : 0xffffff8006f5697b 
> 0xffffff80f7e1bec0 : 0xffffff8006c39cc9 
> 0xffffff80f7e1bef0 : 0xffffff8006c3c7c8 
> 0xffffff80f7e1bf20 : 0xffffff8006c3c63e 
> 0xffffff80f7e1bf50 : 0xffffff8006c1b70d 
> 0xffffff80f7e1bf90 : 0xffffff8006cb8163 
> 0xffffff80f7e1bfb0 : 0xffffff8006cce4bc 
> 
> BSD process name corresponding to current thread: beam.smp
> 
> Mac OS version:
> 12C60

Judging by information from http://fxr.watson.org/fxr/source/bsd/miscfs/specfs/spec_vnops.c?v=xnu-2050.18.24#L1813
I believe the only possible clue we can give is that the issue has
something to do with TTY management and cases when erlang is opened in
a controlling terminal (which is then closed). Maybe this can be prevented somehow.

ps. Most probably (c, 16, 3) is a reference to /dev/ttyS003 device.

> On Nov 26, 2012, at 3:51 PM, Max Lapshin <max.lapshin@REDACTED> wrote:
> 
> > How erlang be guilty in killing kernel of unix OS? It isn't DOS
> > What is the exact mechanism of this Mac failure (and it is definitely Mac failure, not erlang failure).
> > 
> > 
> > On Tue, Nov 27, 2012 at 12:28 AM, <acidbriggs@REDACTED> wrote:
> > Back in March of 2010 it was reported that it was possible to initiate a kernel panic on OS X 10.6.2 with Erlang.
> > 
> > Does anyone know if there is a fix for this? This is still happening in OS X 10.8.2 with Erlang R15B02. I've had it happen on all three of my Macs when working in Emacs and killing an Erlang shell in a buffer in a non-clean way.
> > 
> > I know that the problem was reported to Apple but we know how that is.
> > 
> > Perhaps someone has some sort of patch that can be applied to Erlang that can stop it from exploiting this flaw?
> > 
> > Thanks for your time,
> > 
> > 
> > Briggs
> > 
> > 
> > 
> > 
> > The original thread (http://erlang.org/pipermail/erlang-questions/2010-March/050112.html) stated:
> > 
> > 
> > Greetings,
> > 
> > Using Snow Leopard 10.6.2 and Erlang R13B04 it's possible to cause a
> > kernel panic using the following steps:
> > 
> > 1. Start new terminal window
> > 2. erl +K true -s crypto
> > 3. Cmd-W (close the terminal window without stopping erlang)
> > 
> > Alternatively, if you're running SL 10.6.2 and Erlang R13B03:
> > 
> > 1. Start new terminal window
> > 2. erl +K true -s crypto
> > 3. Cmd-Q (quit the terminal app without stopping erlang)
> > 
> > This appears to work with either 32 or 64 bit builds of Erlang.
> > 
> > 
> > Thanks,
> > 
> > D.
> > 
> > 
> > _______________________________________________
> > 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

-- 
Alexander Zhuravlev