The answer might surprise you.

• https://arxiv.org/abs/1901.01930

Environment

• Erlang/OTP 23 [erts-11.1] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1]
• Interactive Elixir (1.11.2)
• Operating system: MacOS 11.1 (20C69)

Current behavior

given the file crash.ex :

defmodule Crash do
  def curious(value, opts \\ []) do
    width  = Keyword.get(opts, :width, 500.0)
    height = width  / 25.0 
    _middle = if value, do:  width / 2.0, else: 0
    _more = height + 1
  end
end

then

iex(1)> c("crash.ex")

yields:

== Compilation error in file crash.ex == ** (CompileError) Elixir.Crash: function curious/2+33: Internal consistency check failed - please report this bug. Instruction: {bif,fadd,{f,0},[{fr,0},{fr,1}],{fr,0}} Error: {bad_floating_point_state,undefined}:

(stdlib 3.13.2) lists.erl:1342: :lists.foreach/2
(elixir 1.11.2) src/elixir_erl_compiler.erl:12: anonymous fn/3 in :elixir_erl_compiler.spawn/2

** (CompileError) compile error (iex 1.11.2) lib/iex/helpers.ex:200: IEx.Helpers.c/2

This is a pared down example from a real module/function. Most any change in the structure will eliminate the crash.

Thank you! Reported upstream as: https://bugs.erlang.org/browse/ERL-1471

Environment

• Erlang/OTP 23 [erts-11.1] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1]
• Interactive Elixir (1.11.2)
• Operating system: MacOS 11.1 (20C69)

Current behavior

given the file crash.ex :

defmodule Crash do
  def curious(value, opts \\ []) do
    width  = Keyword.get(opts, :width, 500.0)
    height = width  / 25.0 
    _middle = if value, do:  width / 2.0, else: 0
    _more = height + 1
  end
end

then

iex(1)> c("crash.ex")

yields:

== Compilation error in file crash.ex == ** (CompileError) Elixir.Crash: function curious/2+33: Internal consistency check failed - please report this bug. Instruction: {bif,fadd,{f,0},[{fr,0},{fr,1}],{fr,0}} Error: {bad_floating_point_state,undefined}:

(stdlib 3.13.2) lists.erl:1342: :lists.foreach/2
(elixir 1.11.2) src/elixir_erl_compiler.erl:12: anonymous fn/3 in :elixir_erl_compiler.spawn/2

** (CompileError) compile error (iex 1.11.2) lib/iex/helpers.ex:200: IEx.Helpers.c/2

This is a pared down example from a real module/function. Most any change in the structure will eliminate the crash.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Closes #10668

Environment

• Elixir & Erlang/OTP versions (elixir --version): Erlang/OTP 23 [erts-11.1.4] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe] Elixir 1.11.2 (compiled with Erlang/OTP 23)
• Operating system: Mac OS X

Current behavior

File.stream! normalizes linebreaks, which broke the assumption I had: Enum.into(File.stream!(file), <<>>) == File.read!(file)

iex(3)> File.write!("dummy", "test\n2\3")
:ok
iex(4)> File.stream!("dummy") |> Enum.to_list()
["test\n", "23"]
iex(5)> File.write!("dummy", "test\r\n2\3")
:ok
iex(6)> File.stream!("dummy") |> Enum.to_list()
["test\n", "23"]
iex(7)> File.stream!("dummy", [], 2048) |> Enum.to_list()
["test\r\n23"]
iex(8)> File.read!("dummy")
"test\r\n23"

Expected behavior

Either have the normalization of linebreaks documented or have it not happen.

  using the `:line` option, CRLF line breaks (`"\r\n"`) are normalized
  to LF (`"\n"`).

"[{\"success\": false,\"id\": 010,\"text\":\"Arak\"}]" |> Poison.decode! 
** (Poison.SyntaxError) Unexpected token at position 26: 1
    (poison) lib/poison/parser.ex:57: Poison.Parser.parse!/2
    (poison) lib/poison.ex:83: Poison.decode!/2

I am getting this json from "[{\"success\": false,\"id\": 010,\"text\":\"Arak\"}]" some remote website but Poison fails to decode because of 010

EDIT: This JSON wasn't valid.

"[{\"success\": false,\"id\": 010,\"text\":\"Arak\"}]" |> Poison.decode! 
** (Poison.SyntaxError) Unexpected token at position 26: 1
    (poison) lib/poison/parser.ex:57: Poison.Parser.parse!/2
    (poison) lib/poison.ex:83: Poison.decode!/2

I am getting this json from "[{\"success\": false,\"id\": 010,\"text\":\"Arak\"}]" some remote website but Poison fails to decode because of 010

Oi, tudo bem?

Sou do time de desenvolvimento mobile na Foursys, estamos com vagas disponíveis para Android Júnior, Pleno e Sênior, todas 100% remoto, se você está buscando por favor me envie o seu currículo (e-mail [email protected]).

Obrigada.

Closes #10668

Well, it wasn't all :)

• It's rare, but some OTP libs (compiler, syntax_tools, xmerl) use HTML tables in their EDoc docs - table tags are stripped, but the contents are not, so the resulting documentation is probably a mess :|

Thank you for your work!

Environment

Erlang/OTP 23 [erts-11.1.5] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [hipe]

Elixir 1.11.3 (compiled with Erlang/OTP 23)

macOS 11.1 (20C69)

Current behavior

On a project I am maintaining I get the following error when running mix test --cover:

Cover compiling modules ...
** (exit) an exception was raised:
    ** (FunctionClauseError) no function clause matching in :cover."-patch_code1/2-lc$^0/1-1-"/1
        cover.erl:2181: :cover."-patch_code1/2-lc$^0/1-1-"(2)
        cover.erl:2181: :cover.patch_code1/2
        cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
        cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
        cover.erl:2191: :cover.patch_code_tuple/5
        cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
        cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
        cover.erl:1649: :cover.transform/4
    cover.erl:602: :cover.call/1
    (mix 1.11.3) lib/mix/tasks/test.coverage.ex:142: anonymous fn/2 in Mix.Tasks.Test.Coverage.cover_compile/1
    (elixir 1.11.3) lib/enum.ex:2193: Enum."-reduce/3-lists^foldl/2-0-"/3
    (mix 1.11.3) lib/mix/tasks/test.coverage.ex:141: Mix.Tasks.Test.Coverage.cover_compile/1
    (mix 1.11.3) lib/mix/tasks/test.coverage.ex:122: Mix.Tasks.Test.Coverage.start/2
    (mix 1.11.3) lib/mix/tasks/test.ex:336: Mix.Tasks.Test.do_run/3
    (mix 1.11.3) lib/mix/task.ex:394: Mix.Task.run_task/3
    (mix 1.11.3) lib/mix/task.ex:439: Mix.Task.run_alias/5

08:53:12.591 [error] Process #PID<0.3787.0> raised an exception
** (FunctionClauseError) no function clause matching in :cover."-patch_code1/2-lc$^0/1-1-"/1
    cover.erl:2181: :cover."-patch_code1/2-lc$^0/1-1-"(2)
    cover.erl:2181: :cover.patch_code1/2
    cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
    cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
    cover.erl:2191: :cover.patch_code_tuple/5
    cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
    cover.erl:2183: :cover."-patch_code1/2-lc$^1/1-0-"/2
    cover.erl:1649: :cover.transform/4

Expected behavior

The mix task should finish without an error and generate a coverage report.

Thanks for the isolation, it helped a ton. PR to OTP sent here: https://github.com/erlang/otp/pull/2997

Please rename the function for now. :)

If there was an export in the shape of {clauses, Arity}, cover would attempt to handle it as the {clauses, List} AST node, leading to the failure below:

=ERROR REPORT==== 23-Jan-2021::10:04:20.945556 === Error in process <0.159.0> with exit value: {{bad_generator,0}, [{cover,'-patch_code1/2-lc$^0/1-1-',2,[{file,"cover.erl"},{line,2352}]}, {cover,patch_code1,2,[{file,"cover.erl"},{line,2352}]}, {cover,'-patch_code1/2-lc$^1/1-0-',2,[{file,"cover.erl"},{line,2354}]}, {cover,patch_code_tuple,5,[{file,"cover.erl"},{line,2362}]}, {cover,'-patch_code1/2-lc$^1/1-0-',2,[{file,"cover.erl"},{line,2354}]}, {cover,'-patch_code1/2-lc$^1/1-0-',2,[{file,"cover.erl"},{line,2354}]}, {cover,transform,4,[{file,"cover.erl"},{line,1820}]}, {cover,do_compile_beam2,6,[{file,"cover.erl"},{line,1762}]}]}

The fix is to skip all attributes when traversing the forms.

These empirical evidences are only making the case for a "Warning" stronger, to which every body is already consenting to.

The divergence is over the annotation capability, as that improves programming in Erlang better and not the language itself.

नमस्ते। नलिन रंजन

On Sat, Jan 23, 2021, 10:57 AM Michael Klishin [email protected] wrote:

We now have some practical examples of what this feature could reveal in real world open source projects.

@richcarl https://github.com/richcarl experimented with annotating the OTP codebase and published his findings http://erlang.org/pipermail/erlang-questions/2021-January/100468.html. This seems to be very promising, so @kjnilsson https://github.com/kjnilsson decided to do the same thing to one of the smaller but key RabbitMQ dependencies, Ra. We also found code that looks suspicious as a result: rabbitmq/ra#209 https://github.com/rabbitmq/ra/pull/209.

In a few days worth of work, this helped reveal potential bugs in pretty complex Erlang codebases.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/erlang/otp/pull/2951#issuecomment-765870516, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRD7V2FYSMQGXKTW4D6V6TS3JM4JANCNFSM4VIPVJ2A .

We now have some practical examples of what this feature could reveal in real world open source projects.

@richcarl experimented with annotating the OTP codebase and published his findings. This seems to be very promising, so @kjnilsson decided to do the same thing to one of the smaller but key RabbitMQ dependencies, Ra. We also found code that looks suspicious as a result: https://github.com/rabbitmq/ra/pull/209.

In a few days worth of time, this helped reveal potential bugs in pretty complex Erlang codebases.

@garazdawi could we get the benchmark from #2983 for this one so we can compare ?

@kjellwinblad following what @uabboli is saying, what would you like to get in term of additional tests, if any, to progress in this ?

To my knowledge, upcoming release still has original gen_tcp backend as default. Also, I am not sure whether distribution over TLS will use "socket" instead of gen_tcp, or will use "socket" backend for gen_tcp. Therefore I assume this change is still helpful.

Hi @josevalim,

got it! It is a function with the name clauses. You can reproduce it by creating a new project via mix new foobar and create a function with the name clauses in the module. mix test --cover will fail with the error described above.

I created an example project at https://github.com/ckruse/foobar

Thank you @fertapric, I see what @wojtekmach meant now.

@eksperimental here is the list of fields

https://github.com/elixir-lang/elixir/blob/898d80e46c78b006cc1b951208e53fe7c67c02a1/lib/elixir/lib/inspect.ex#L473-L489

I believe the elipsis is for the hidden fields.

these fields are missing

  tracers: [],
  unused_vars: {%{}, 0},
  vars: []

I believe the elipsis is for the hidden fields.

It still does not work as expected. Note the ellipsis at the end.

iex(1)> IO.inspect __ENV__, limit: :infinity                
#Macro.Env<
  aliases: [],
  context: nil,
  context_modules: [],
  file: "iex",
  function: nil,
  functions: [
    {IEx.Helpers,
     [
       break!: 3,
       break!: 4,
       breaks: 0,
       c: 1,
       c: 2,
       cd: 1,
       clear: 0,
       continue: 0,
       exports: 0,
       exports: 1,
       flush: 0,
       h: 0,
       i: 0,
       i: 1,
       l: 1,
       ls: 0,
       ls: 1,
       nl: 1,
       nl: 2,
       open: 0,
       pid: 1,
       pid: 3,
       port: 1,
       port: 2,
       pwd: 0,
       r: 1,
       recompile: 0,
       recompile: 1,
       ref: 1,
       ref: 4,
       remove_breaks: 0,
       remove_breaks: 1,
       reset_break: 1,
       reset_break: 3,
       respawn: 0,
       runtime_info: 0,
       runtime_info: 1,
       v: 0,
       v: 1,
       whereami: 0,
       whereami: 1
     ]},
    {Kernel,
     [
       !=: 2,
       !==: 2,
       *: 2,
       +: 1,
       +: 2,
       ++: 2,
       -: 1,
       -: 2,
       --: 2,
       /: 2,
       <: 2,
       <=: 2,
       ==: 2,
       ===: 2,
       =~: 2,
       >: 2,
       >=: 2,
       abs: 1,
       apply: 2,
       apply: 3,
       binary_part: 3,
       bit_size: 1,
       byte_size: 1,
       ceil: 1,
       div: 2,
       elem: 2,
       exit: 1,
       floor: 1,
       function_exported?: 3,
       get_and_update_in: 3,
       get_in: 2,
       hd: 1,
       inspect: 1,
       inspect: 2,
       is_atom: 1, 
       is_binary: 1,
       is_bitstring: 1,
       is_boolean: 1,
       is_float: 1,
       is_function: 1,
       is_function: 2,
       is_integer: 1,
       is_list: 1,
       is_map: 1,
       is_map_key: 2,
       is_number: 1,
       is_pid: 1,
       is_port: 1,
       is_reference: 1,
       is_tuple: 1,
       length: 1,
       macro_exported?: 3,
       make_ref: 0,
       map_size: 1,
       max: 2,
       min: 2,
       node: 0,
       node: 1,
       not: 1,
       pop_in: 2,
       put_elem: 3,
       put_in: 3, 
       rem: 2,
       round: 1,
       self: 0,
       send: 2,
       spawn: 1,
       spawn: 3,
       spawn_link: 1,
       spawn_link: 3,
       spawn_monitor: 1,
       spawn_monitor: 3,
       struct: 1,
       struct: 2,
       struct!: 1,
       struct!: 2,
       throw: 1,
       tl: 1,
       trunc: 1,
       tuple_size: 1,
       update_in: 3
     ]}
  ],
  lexical_tracker: nil,
  line: 1,
  macro_aliases: [],
  macros: [
    {IEx.Helpers,
     [
       b: 1,
       break!: 1,
       break!: 2,
       h: 1,
       import_file: 1,
       import_file: 2,
       import_file_if_available: 1,
       import_if_available: 1,
       import_if_available: 2,
       open: 1,
       t: 1,
       use_if_available: 1,
       use_if_available: 2
     ]},
    {Kernel,
     [
       !: 1,
       &&: 2,
       ..: 2,
       <>: 2,
       @: 1,
       alias!: 1,
       and: 2,
       binding: 0,
       binding: 1,
       def: 1,
       def: 2,
       defdelegate: 2,
       defexception: 1,
       defguard: 1,
       defguardp: 1,
       defimpl: 2,
       defimpl: 3,
       defmacro: 1,
       defmacro: 2,
       defmacrop: 1,
       defmacrop: 2,
       defmodule: 2,
       defoverridable: 1,
       defp: 1,
       defp: 2,
       defprotocol: 2,
       defstruct: 1,
       destructure: 2,
       get_and_update_in: 2,
       if: 2,
       in: 2,
       is_exception: 1,
       is_exception: 2,
       is_nil: 1,
       is_struct: 1,
       is_struct: 2,
       match?: 2,
       or: 2,
       pop_in: 1,
       put_in: 2,
       raise: 1,
       raise: 2,
       reraise: 2,
       reraise: 3,
       sigil_C: 2,
       sigil_D: 2,
       sigil_N: 2,
       sigil_R: 2,
       sigil_S: 2,
       sigil_T: 2,
       sigil_U: 2,
       sigil_W: 2,
       sigil_c: 2,
       sigil_r: 2,
       sigil_s: 2,
       sigil_w: 2,
       tap: 2,
       then: 2,
       to_char_list: 1,
       to_charlist: 1,
       to_string: 1,
       unless: 2,
       update_in: 2,
       use: 1,
       use: 2,
       var!: 1,
       var!: 2,
       |>: 2,
       ||: 2
     ]}
  ],
  module: nil,
  requires: [Application, IEx.Helpers, Kernel, Kernel.Typespec],
  ...
>

Using the new socket api avoids this problem (since you have more control). Is gen_tcp not going to be deprecated / put ontop of it by default?

But nice.