evax ( Evax Software )

Cannot reallocate 0 bytes of memory (of type "estack")

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

comment created time in 3 hours

OTP 23 beam can‘t auto gc on a CentOS 7 server

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

closed time in 3 hours

TangYunTao

issue commenterlang/otp

OTP 23 beam can‘t auto gc on a CentOS 7 server

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.

TangYunTao

comment created time in 3 hours

issue commenterlang/otp

ssl psk ciphers options break between ssl 9.2 and 10.1

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.

danj3

comment created time in 3 hours

pull request commenterlang/otp

doc: Fix spelling errors

@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.

lagebr

comment created time in 3 hours

issue openederlang/otp

lists:search/2 documentation and implementation disagree about non-true return values of Pred function

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.

created time in 5 hours

Pull request review commenterlang/otp

Clean up and support reuse of distribution capability bits

 -define(DFLAG_EXIT_PAYLOAD, 16#400000). -define(DFLAG_FRAGMENTS,    16#00800000). -define(DFLAG_HANDSHAKE_23, 16#01000000).--define(DFLAG_RESERVED,     16#fe000000).--define(DFLAG_SPAWN,       16#100000000).--define(DFLAG_NAME_ME,     16#200000000).--define(DFLAG_V4_NC,       16#400000000).--define(DFLAG_ALIAS,       16#800000000).+-define(DFLAG_MANDATORY_25, 16#04000000).

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

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

bjorng

comment created time in 6 hours

Pull request review commenterlang/otp

Clean up and support reuse of distribution capability bits

 -define(ERL_DIST_VER_LOW, ?ERL_DIST_VER_5). -define(ERL_DIST_VER_HIGH, ?ERL_DIST_VER_6). +%%%+%%% To avoid having to extend the number of distribution flags from 64+%%% to 128, an scheme for garbage collection of the flags was

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

bjorng

comment created time in 6 hours

Pull request review commenterlang/otp

Clean up and support reuse of distribution capability bits

 #define DFLAG_DIST_STRICT_ORDER DFLAG_DIST_HDR_ATOM_CACHE  /* All flags that should be enabled when term_to_binary/1 is used. */-#define TERM_TO_BINARY_DFLAGS (DFLAG_EXTENDED_REFERENCES	\-			       | DFLAG_NEW_FUN_TAGS		\-			       | DFLAG_NEW_FLOATS		\-			       | DFLAG_EXTENDED_PIDS_PORTS	\-			       | DFLAG_EXPORT_PTR_TAG		\-			       | DFLAG_BIT_BINARIES             \-			       | DFLAG_MAP_TAG                  \-                               | DFLAG_BIG_CREATION)+#define TERM_TO_BINARY_DFLAGS DFLAG_NEW_FLOATS

#define TERM_TO_BINARY_DFLAGS 0

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

bjorng

comment created time in 6 hours

Pull request review commenterlang/otp

Clean up and support reuse of distribution capability bits

 dflag2str(?DFLAG_FRAGMENTS) ->     "FRAGMENTS"; dflag2str(?DFLAG_HANDSHAKE_23) ->     "HANDSHAKE_23";

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

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

bjorng

comment created time in 6 hours

push eventerlang/otp

Micael Karlberg

commit sha 269a7d1961b3e61237afc4378b2046c298b2c76f

[kernel] Improve inet:info/1 The info function did not handle a closed socket well. A 'closed' socket is represented by a info map with *only* the one or two states-attributes, with the value(s) set to [closed]. Also if the function is called for a non-socket port, behave as well as possible (no status or statistics). OTP-17492 [kernel] More tweaking