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

Closes #241

The return value here is a 5 element tuple, rather than the 4 element tuple declared in the typespec:

The typespec:

https://github.com/elixir-ecto/db_connection/blob/4d7e789943f1c3a0b54b871f3807a04303e666dc/lib/db_connection/holder.ex#L50

The offenders:

https://github.com/elixir-ecto/db_connection/blob/4d7e789943f1c3a0b54b871f3807a04303e666dc/lib/db_connection/holder.ex#L57

https://github.com/elixir-ecto/db_connection/blob/4d7e789943f1c3a0b54b871f3807a04303e666dc/lib/db_connection/holder.ex#L77

Closes #241

The return value here is a 5 element tuple, rather than the 4 element tuple declared in the typespec:

https://github.com/elixir-ecto/db_connection/blob/master/lib/db_connection/holder.ex#L57

You can send the crash dump to rickard at erlang.org

This is not a bug. A process is not garbage collected unless it reach certain limits, for example it needs to allocate heap data and there is no free heap available. If a process stops executing, it does not matter how long time passes, it wont automatically garbage collect by itself unless it reaches one of these limits.

Describe the bug OTP 23 beam can‘t auto gc on a CentOS 7 server，and call 'erlang:garbage_collect' effectively frees the process's memory; and It works on mac

To Reproduce Steps to reproduce the behavior.

Expected behavior after the client establishes a connection to the server, the process takes 40K bytes and does not release it

Affected versions otp 23

Additional context gc.md

There seems to be a larger problem with option handling. After changing the options to look like this:

    SslOptions = [
                  { verify, verify_none },
                  { psk_identity, "TESTID" },
                  { versions, [ 'tlsv1.2' ] },
                  { user_lookup_fun, { fun psk_lookup/3, nil } },
                  { ciphers, [
                              #{
                                cipher => aes_128_cbc,
                                key_exchange => psk,
                                mac => sha,
                                prf => default_prf
                               }
                             ]
                  }
                 ],

I run the same test using a docker container based on alpine, which does not include and ca-certificates by default and the error produced was:

=WARNING REPORT==== 18-Jun-2021::19:32:38.925569 ===
Description: "Authenticity is not established by certificate path validation"
     Reason: "Option {verify, verify_peer} and cacertfile/cacerts is missing"

But {verify, verify_none} is set. Using versions [ 'tlsv1.2' ] did not alter the outcome.

@lagebr you need to do a rebase --onto and force push your branch, moving things backwards with github button does not work I am afraid.

Describe the bug

The man page for lists (lib/stdlib/doc/src/lists.xml) describes the lists:search/2 function as

• search(Pred, List) -> {value, Value} | false If there is a Value in List such that Pred(Value) returns true, returns {value, Value} for the first such Value, otherwise returns false.

This makes no mention whatsoever about what the Pred(Value) call needs to return if it does not return true, so all values which are not the atom true should be valid according to that description.

However, the implementation of lists:search/2 in lib/stdlib/src/lists.erl is more strict and insists that Pred(Value) MUST return either the atom true or the atom false, which is also reflected by its -spec specifying a boolean() return value.

-spec search(Pred, List) -> {value, Value} | false when
      Pred :: fun((T) -> boolean()),
      List :: [T],
      Value :: T.

search(Pred, [Hd|Tail]) ->
    case Pred(Hd) of
        true -> {value, Hd};
        false -> search(Pred, Tail)
    end;
search(Pred, []) when is_function(Pred, 1) ->
    false.

To Reproduce

Run this script:

#!/usr/bin/env escript
%% -*- erlang -*-

main([]) ->
    lists:search(fun(X) ->
			 case X rem 2 of
			     0 -> true;
			     _ -> odd
			 end
		 end,
		 [5,1,3,2,9,14]),
    ok.

[user@host ~]$ escript lists-search-pred-values
escript: exception error: no case clause matching odd
  in function  lists:search/2 (lists.erl, line 1412)
  in call from erl_eval:do_apply/6 (erl_eval.erl, line 680)
  in call from escript:eval_exprs/5 (escript.erl, line 872)
  in call from erl_eval:local_func/6 (erl_eval.erl, line 567)
  in call from escript:interpret/4 (escript.erl, line 788)
  in call from escript:start/1 (escript.erl, line 277)
  in call from init:start_em/1 
  in call from init:do_boot/3 
[user@host ~]$ 

Yes, this example fun may look a bit contrived, but with a number of OTP functions such as lists:search/2 or lists:keysearch/3 returning either {value, Value} or false, there are certainly precedents for a function returning either a boolean value or something that is not a boolean value at all not being very unusual.

Expected behavior

If the documentation is correct, the escript should run without throwing an exception.

Affected versions

All OTP versions since the introduction of lists:search/2 which, according to lists.xml, was OTP 21.0. In my case, OTP 23.

Additional context

I see two ways to fix this:

• either fix the documentation to explicitly demand that Pred(Value) needs to return either true or false
• or fix the implementation (and the -spec) to allow for any non-true value to be interpreted as currently false is

There are arguments for both ways. Fixing the implementation appears to allow all non-true values appears to be the more Erlang-y way to me, though, and should change much in the code (not sure whether the -spec for Pred is a good way to express this, though):

-spec search(Pred, List) -> {value, Value} | false when
      Pred :: fun((T) -> true | term()),
      List :: [T],
      Value :: T.

search(Pred, [Hd|Tail]) ->
    case Pred(Hd) of
        true -> {value, Hd};
        _ -> search(Pred, Tail)
    end;
search(Pred, []) when is_function(Pred, 1) ->
    false.

-define(DFLAG_UNLINK_ID, 16#02000000).
-define(DFLAG_MANDATORY_25, 16#04000000).

I seem to have forgotten the DFLAG_UNLINK_ID flag here...

%%% to 128, a scheme for garbage collection of the flags was

#define TERM_TO_BINARY_DFLAGS 0

Since DFLAG_NEW_FLOATS now are mandatory, or maybe I'm missing something?

    "HANDSHAKE_23";
dflag2str(?DFLAG_UNLINK_ID) ->
    "UNLINK_ID";

I seem to have forgotten the DFLAG_UNLINK_ID flag here...

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

Precisely, thanks @thiamsantos and @JEG2!

I think it is the same error reported at https://github.com/elixir-lang/elixir/issues/11014. It seems to be already fixed in OTP https://github.com/erlang/otp/commit/c1942e39d44d50bb4bdf8e22456f31ee23931fdb.

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

@rickard-green: thanks, it looks like #4980 resolves the issue!

Applying it to OTP-23.3.4.4 and OTP-24.0.2, the above repro example runs cleanly in the standard and debug emulators, and the behavior above no longer occurs. Without the patch, one of the following still occurs:

1. schedulers_online value stops changing / processes get stuck (standard+debug)
2. emulator aborts with assertion (debug)

Will look into enabling more extensive local testing.

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

Yes, it should work for "all" kinds of sockets. The function socket:monitor/1 is official, but is intended for when you only work with 'socket' sockets.