

How to crash Erlang - mbrubeck
http://prog21.dadgum.com/43.html

======
mononcqc
quoting myself from reddit:

About atoms: "calling integer_to_list and then list_to_atom on the current
loop index."

There is a function called 'list_to_existing_atom' done to circumvent that.
Note that each atom is only 4 bytes (8 bytes in a 64bit system) and you have
to use several hundred of thousands of them for it to be problematic. As long
as you don't dynamically create atoms from user input, it's not a problem.

Point 2 about 'process leaks' is valid, but fixable by the programmer again.
Just make sure processes can die, or create a pool (what servers like mochiweb
and YAWS do, as far as I know).

Flooding a mailbox has bitten lots of people in the ass, and is even a problem
in the default settings of the OTP logger. Lots of people have gotten problems
with the selective pattern match making their app die (too much in, not enough
out). It's probably the biggest menace for an Erlang VM because it mainly
becomes apparent under heavy load, which is sometimes harder to simulate and
test for.

As for the binary problem, a general behavior causing the problem is that when
you split a large binary, the fragments are just references to the big one
until the process dies. So using these can often mean you'll mess up the
reference counting. A work-around for that is to call a variation of
"list_to_binary(binary_to_list(Bin))" which will allocate the binary as a new
one separate from the large one.

Erlang definitely has problems, but to crash the VM with them takes some kind
of mistake or lack of awareness on the programmer's side. I'm not writing this
to contradict James Hague (he's one of the bloggers I like the most), just
thought I'd complete/comment.

------
noss
> Now that's a loaded title, and I know some people will > immediately see it
> as a personal slam on Erlang or > ammunition for berating the language in
> various forums.

Instead, this is actually a quite good discriminator for those that understand
high availability programming in Erlang and those that do not.

E.g. Erlang is about programming in the presence of failure, not about having
eliminated everything that could possibly fail.

