Segmentation fault on OTP27

[martosaur]

Describe the bug
Running this function results in a segmentation fault

defmodule Example do
  def foo() do
    %{
      prev: nil,
      next: [equal: "a", delete: "y", equal: "x"]
    }
    |> recursive({"", ""})
  end

  defp recursive(%{next: []}, _), do: IO.inspect(:ok)

  defp recursive(%{next: [{op, text} | next]} = diffs,
         {text_delete, text_insert}
       ) do
    acc =
      case op do
        :insert ->
          {text_delete, text_insert <> text}

        :delete ->
          {text_delete <> text, text_insert}

        :equal ->
          {"", ""}
      end

    %{
      prev: diffs.prev,
      next: next,
    }
    |> recursive(acc)
  end
end

Example.foo()

To Reproduce
Run the elixir script with OTP27

Expected behavior
Function should run normally

Affected versions
Affected:

• 27.0
• 27.1.2
• ref:maint-27

Not affected:

• 26.2.5.5

Additional context
Please excuse the absurd example, but this is what I could boil down the function to from the original version. Almost any part seems to be important: making recursive function public, matching on prev in function head, removing unused :insert -> clause - all fixes the issue.

[frej]

I know almost nothing about Elixir (and don't have the toolchain installed), but as this looks like a recursive function updating an accumulator represented by a tuple, it could be a fault with the destructive update of tuples optimization (new in OTP-27).

If you were running plain old Erlang and compiling the module with the compiler option +no_ssa_opt_destructive_update made the segfault go away, it was probably triggered by the above mentioned optimization. According to Google, including @compile {:no_ssa_opt_destructive_update} in your module should pass the flag to the Erlang compiler. If that makes the segfault go away, I would be helped by a dump of your module in Erlang abstract format.

[bjorng]

@frej,

Here is the code translated to Erlang and slightly simplified:

-module(crash).
-export([foo/0]).

foo() ->
    recursive(#{prev => nil,
                next =>
                    [{equal, <<"a">>},
                     {delete, <<"y">>}]},
              {<<>>, <<>>}).

recursive(#{next := [{Op, Text} | Next]} = Diffs,
          {TextDelete, TextInsert}) ->
    Acc =
        case Op of
            insert ->
                {TextDelete,
                 <<TextInsert/binary,Text/binary>>};
            delete ->
                {<<TextDelete/binary,Text/binary>>,
                 TextInsert};
            equal ->
                {<<>>, <<>>}   %% Bug is here.
        end,
    recursive(#{prev =>
                    case Diffs of
                        #{prev := Prev} ->
                            Prev;
                        Other ->
                            ?MODULE:no_parens_remote(Other)
                    end,
                next => Next},
              Acc).

The bug seems to be in the code for line 22. Only one of the empty binaries is created using bs_init_writable.

[frej]

Thanks Björn, I'll take a look as soon as I finish up another thing.

[frej]

@bjorng: It's an error in how a a phi-instruction with literals is patched in the destructive update pass. If more than one element of a literal tuple is patched to get its value from bs_init_writable, only one patch will be applied. So it's pretty much local to that case, i.e. it's not any major fault in the alias analysis. Expect a patch on Monday.

For now, @martosaur, compile your module with +no_ssa_opt_destructive_update to work around the bug (the performance should be as for OTP26 then).