Richard Carlsson | 22 Aug 14:22 2014
Picon

error in documentation of erl +swct flag

The erl documentation (http://www.erlang.org/doc/man/erl.html) currently says:
+sws very_eager|eager|medium|lazy|very_lazy

Set scheduler wake cleanup threshold. Default is medium. This flag controls how eager schedulers should be requesting wake up due to certain cleanup operations. When a lazy setting is used, more outstanding cleanup operations can be left undone while a scheduler is idling. When an eager setting is used, schedulers will more frequently be woken, potentially increasing CPU-utilization.

NOTE: This flag may be removed or changed at any time without prior notice.

+sws default|legacy

Set scheduler wakeup strategy. Default strategy changed in erts-5.10/OTP-R16A. This strategy was previously known as proposal in OTP-R15. The legacy strategy was used as default from R13 up to and including R15.

NOTE: This flag may be removed or changed at any time without prior notice.


I think that the first of these should be +swct (which was first mentioned in the R16B01 release notes).

        /Richard

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Jesper Louis Andersen | 18 Aug 14:36 2014
Picon

Problem with binary_to_integer/1 and list_to_integer/1 (QuickCheck test case)

Hi,

While working on transit-erlang, Isaiah Peng and I found what we believe to be a bug in the Erlang compiler:

9> A = -576460752303423488.
-576460752303423488
10> B = binary_to_integer(integer_to_binary(A)).
-576460752303423488
11> A == B.
false
12> A.
-576460752303423488
13> B.
-576460752303423488
14>

I expected command 11 (A == B) to return true, as the numbers are the same. But it looks like constants are not treated the same way as converted vaues for some reason and the equality test fails.

This fails in the interpreter and in compiled code. It *also* fails with list_to_integer/1 and integer_to_list/1.  The number is not chosen arbitrarily. It is -1 * 2^59 which is a borderline number on a 64bit machine. (OTP release 17.1). Isaiah notes that these borderline numbers are not caught by the OTP test cases. They probably should be.

In the interest of full exploration, I've written a QuickCheck test case to catch the remaining trouble. It explicitly tests the borderline numbers and only finds this error.


-module(integer_coding). -compile(export_all). -include_lib("eqc/include/eqc.hrl"). power(_N, 0) -> 1; power(N, P) -> N * power(N, P-1). perturb() -> elements([0, 1, -1, 2, -2, 3, -3, 4, -4, 5, -5]). sign() -> elements([1, -1]). nat_power() -> frequency([{1, elements([27, 28, 29, 31, 32, 33, 59, 60, 61, 63, 64, 65])}, {1, nat()}]). interesting_int() -> ?LET({K, Sign, Perturb}, {nat_power(), sign(), perturb()}, power(2, K)*Sign + Perturb). prop_binary_iso() -> ?FORALL(K, interesting_int(), begin I = binary_to_integer(integer_to_binary(K)), I == K end). prop_list_iso() -> ?FORALL(K, interesting_int(), begin I = list_to_integer(integer_to_list(K)), I == K end). all() -> eqc:module({numtests, 3000}, ?MODULE). t() -> eqc:quickcheck(eqc:testing_time(300, prop_binary_iso())). [...] Produces: 8> integer_coding:all(). prop_list_iso: .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Failed! After 1498 tests. -576460752303423488 prop_binary_iso: ...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Failed! After 588 tests. -576460752303423488 [prop_list_iso,prop_binary_iso] 9>


--
J.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Michael Truog | 30 Jul 21:37 2014
Picon

inets stand_alone mode

Hi,

I ran into a problem that exists in 17.1.2 with inets between inets mode and stand_along mode with httpc:

This works:
1> application:start(inets).
ok
2> inets:start(httpc, [{profile, foobar}], inets).
{ok,<0.53.0>}
3> inets:start(httpc, [{profile, foobar}], inets).
{error,{already_started,<0.53.0>}}

This is the problem (unable to use a try/catch to get the exit, since that is within an inets process):
1> inets:start(httpc, [{profile, foobar}], stand_alone).
{ok,<0.35.0>}
2> inets:start(httpc, [{profile, foobar}], stand_alone).

=ERROR REPORT==== 30-Jul-2014::12:24:22 ===
** Generic server <0.35.0> terminating
** Last message in was {'EXIT',<0.33.0>,
                         {'EXIT',
                          {badarg,
                           [{ets,new,
                             [stand_alone_foobar__session_db,
                              [public,set,named_table,{keypos,2}]],
                             []},
                            {httpc_manager,do_init,2,
[{file,"httpc_manager.erl"},{line,421}]},
                            {httpc_manager,init,1,
[{file,"httpc_manager.erl"},{line,406}]},
                            {gen_server,init_it,6,
                             [{file,"gen_server.erl"},{line,306}]},
                            {proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}}}
** When Server state == {state,[],stand_alone_foobar__handler_db,
                             {cookie_db,undefined,16402},
stand_alone_foobar__session_db,stand_alone_foobar,
                             {options,
                                 {undefined,[]},
                                 {undefined,[]},
0,2,5,120000,2,disabled,false,inet,default,
                                 default,[]}}
** Reason for termination ==
** {'EXIT',{badarg,[{ets,new,
                          [stand_alone_foobar__session_db,
                           [public,set,named_table,{keypos,2}]],
                          []},
                     {httpc_manager,do_init,2,
[{file,"httpc_manager.erl"},{line,421}]},
                     {httpc_manager,init,1,
[{file,"httpc_manager.erl"},{line,406}]},
                     {gen_server,init_it,6,
[{file,"gen_server.erl"},{line,306}]},
                     {proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}}
** exception exit: {'EXIT',
                        {badarg,
                            [{ets,new,
                                 [stand_alone_foobar__session_db,
[public,set,named_table,{keypos,2}]],
                                 []},
                             {httpc_manager,do_init,2,
[{file,"httpc_manager.erl"},{line,421}]},
                             {httpc_manager,init,1,
[{file,"httpc_manager.erl"},{line,406}]},
                             {gen_server,init_it,6,
[{file,"gen_server.erl"},{line,306}]},
                             {proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}}

I am not sure if this was a known issue, but it should be a bug, since it seems valid that two standalone Erlang
processes might use the same httpc profile data in ets.

Thanks,
Michael
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

PAILLEAU Eric | 28 Jul 23:56 2014
Picon

17.0 : dialyzer issue on boolean type in record.

Hi,
please considere below minimal module :
---8<----------------------------------------------------
-module(test).

-export([test/0]).

-record(test, { bool   = 'true' :: boolean()} ).

test() -> test(#test{}).

test(R) -> case R#test.bool of
                 true  -> ok ;
                 false -> ok
            end.
---8<----------------------------------------------------
dialyzer raise an error :

test.erl:11: The pattern 'false' can never match the type 'true'.

Looks like dialyzer considere #test.bool to be of type 'true' while it 
is of type boolean() and default value to 'true'.

Documentation says :
"In the presence of initial values for fields, the type must be declared 
after the initialization as in the following:

   -record(rec, {field1 = [] :: Type1, field2, field3 = 42 :: Type3}).

Naturally, the initial values for fields should be compatible with (i.e. 
a member of) the corresponding types. "

A bug, isn't it ?

Regards.

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Mikael Pettersson | 28 Jul 16:27 2014
Picon

r15b03-1 SEGV in erts_port_task_schedule()

This is a followup to my previous report in
<http://erlang.org/pipermail/erlang-bugs/2014-June/004451.html>,
but it's for a different function in erl_port_task.c.

We've gotten a new SEGV with r15b03-1.  This time we managed to
capture a truncated core dump (just threads list and registers,
no thread stacks or heap memory):

Program terminated with signal 11, Segmentation fault.
#0  enqueue_task (ptp=<optimized out>, 
    ptqp=<error reading variable: Cannot access memory at address 0x7f8f02a95d08>)
    at beam/erl_port_task.c:327
327         ptp->prev = ptqp->last;
(gdb) bt
#0  enqueue_task (ptp=<optimized out>, 
    ptqp=<error reading variable: Cannot access memory at address 0x7f8f02a95d08>)
    at beam/erl_port_task.c:327
#1  erts_port_task_schedule (id=<optimized out>, 
    id <at> entry=<error reading variable: Cannot access memory at address 0x7f8efdeb8318>, 
    pthp=<error reading variable: Cannot access memory at address 0x7f8efdeb82c0>, 
    type=<error reading variable: Cannot access memory at address 0x7f8efdeb82cc>, 
    event=<error reading variable: Cannot access memory at address 0x7f8efdeb82d0>, 
    event_data=<error reading variable: Cannot access memory at address 0x7f8efdeb82d8>)
    at beam/erl_port_task.c:615
(gdb) 

The code that faulted is

   0x00000000004b8203 <+419>:   mov    0x10(%r15),%rax
   0x00000000004b8207 <+423>:   mov    0x10(%rsp),%rbx
   0x00000000004b820c <+428>:   movq   $0x0,0x8(%rbx)
=> 0x00000000004b8214 <+436>:   mov    0x8(%rax),%rcx
   0x00000000004b8218 <+440>:   mov    %rax,0x10(%rbx)
   0x00000000004b821c <+444>:   mov    %rcx,(%rbx)

which is enqueue_task() [line 327] as inlined in erts_port_task_schedule()
[line 615].  At this point, %rax is zero according to gdb's registers dump.

The relevant part of erts_port_task_schedule() is:

==snip==
    if (!pp->sched.taskq)
	pp->sched.taskq = port_taskq_init(port_taskq_alloc(), pp);

    ASSERT(ptp);

    ptp->type = type;
    ptp->event = event;
    ptp->event_data = event_data;

    set_handle(ptp, pthp);

    switch (type) {
    case ERTS_PORT_TASK_FREE:
	erl_exit(ERTS_ABORT_EXIT,
		 "erts_port_task_schedule(): Cannot schedule free task\n");
	break;
    case ERTS_PORT_TASK_INPUT:
    case ERTS_PORT_TASK_OUTPUT:
    case ERTS_PORT_TASK_EVENT:
	erts_smp_atomic_inc_relb(&erts_port_task_outstanding_io_tasks);
	/* Fall through... */
    default:
	enqueue_task(pp->sched.taskq, ptp);
	break;
    }
==snip==

The SEGV implies that pp->sched.taskq is NULL at the call to enqueue_task().

The erts_smp_atomic_inc_relb() and set_handle() calls do not affect *pp,
and I don't see any aliasing between *ptp and *pp, so the assignments to
*ptp do not affect *pp either.

So for pp->sched.taskq to be NULL at the bottom it would have to be NULL
after the call to port_taskq_init(), which implies that port_taskq_alloc()
returned NULL.

port_taskq_alloc() is generated via ERTS_SCHED_PREF_QUICK_ALLOC_IMPL;
if one expands that it becomes:

void erts_alloc_n_enomem(ErtsAlcType_t,Uint)
     __attribute__((noreturn));

static __inline__
void *erts_alloc(ErtsAlcType_t type, Uint size)
{
    void *res;
    res = (*erts_allctrs[(((type) >> (0)) & (15))].alloc)(
	(((type) >> (7)) & (255)),
	erts_allctrs[(((type) >> (0)) & (15))].extra,
	size);
    if (!res)
	erts_alloc_n_enomem((((type) >> (7)) & (255)), size);
    return res;
}

static __inline__ ErtsPortTaskQueue * port_taskq_alloc(void)
{
    ErtsPortTaskQueue *res = port_taskq_pre_alloc();
    if (!res)
	res = erts_alloc((4564), sizeof(ErtsPortTaskQueue));
    return res;
}

But given this code, I don't see how erts_alloc() or port_taskq_alloc()
could ever return NULL.

Which leads me to suspect that there's a concurrency bug that's
causing *pp to be clobbered behind our backs.

Ideas?

/Mikael
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Louis-Philippe Gauthier | 25 Jul 17:49 2014

erl_lock_count segfault

Hi,
Looks like in some certain conditions I get a segfault when starting the VM when compiled with lock counter.


LP
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
o鸡蛋黄o | 24 Jul 05:03 2014

erlang vm crash/coredump

Jul 23 19:11:31 imtestserver kernel: [27024.541714] TCP: TCP: Possible SYN flooding on port 5222. Sending cookies.  Check SNMP counters.
Jul 23 19:12:14 imtestserver kernel: [27067.574868] beam.smp[7347]: segfault at 20 ip 00000000005342d4 sp 00007f343baf5d00 error 4 in beam.smp[400000+267000]
Jul 23 19:14:22 imtestserver kernel: [27196.203390] TCP: TCP: Possible SYN flooding on port 5222. Sending cookies.  Check SNMP counters.
Jul 23 19:15:01 imtestserver CRON[7894]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jul 23 19:19:32 imtestserver kernel: [27505.432769] beam.smp[7643]: segfault at 20 ip 00000000005342d4 sp 00007f2d98f76d00 error 4 in beam.smp[400000+267000]

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Michael Truog | 22 Jul 00:55 2014
Picon

Dialyzer Bugs

There are two dialyzer bugs that I ran into recently:
1) In 17.1 passing a symbolic link to the --plt option doesn't work as it once did (it is still ok to have
~/.dialyzer_plt as a symbolic link)

2) -Wrace_conditions causes the dialyzer execution time to vary with the possibility that dialyzer
execution will not finish.  The memory of dialyzer can also grow to much larger sizes >1GB while this
occurs.  I had this occur awhile ago with R16B03-1 while leaving dialyzer to run and it refused to finish
after roughly 40 minutes when a normal run takes 1 minute (roughly).  I recently talked to a person on IRC
(freenode in the #erlang room) which had the same problem where the person's dev machine was affected but
the CI server never had any problem completing the dialyzer runs.  It seems like this appears only when a
sufficiently large amount of Erlang source code is used for the dialyzer run.  The person suspected that a
corrupt file might have caused the problem to appear, but I doubted
  that -Wrace_conditions would be modifying any state on disk (it wouldn't be changing a PLT file, right?).

Thanks,
Michael

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Tomas Abrahamsson | 20 Jul 03:27 2014
Picon

enif_make_int64 => -0 for INT64_MIN with gcc 4.9.1

Hi,

I upgraded gcc from version 4.8.1 to 4.9.1, recompiled Erlang/OTP-17.1.1
and my nif, and now enif_make_int64 creates -0 for INT64_MIN.

  % make test
  erl -s int64nif go -s erlang halt
  Erlang/OTP 17 [erts-6.1.1] [source] [smp:4:4] [async-threads:10]
[kernel-poll:false]

  -0

When Erlang was compiled with gcc-4.8.1, it printed -9223372036854775808,
I've attached the test programs, here are the important lines:

    go() ->
        io:format("~p~n", [int64_from_nif()]).

The NIF C-code contains:

    static ERL_NIF_TERM
    int64_from_nif(ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[])
    {
        return enif_make_int64(env, INT64_MIN);
    }

System information:

  OS: linux, 32-bit core i5, 3.14-1-686-pae (debian unstable)
  Erlang/OTP: built from scratch (both times) from the OTP-17.1.1 git tag.
  gcc: initially: gcc (Debian 4.8.1-10) 4.8.1
       with this one, it prints -9223372036854775808
  gcc: after upgrade: gcc (Debian 4.9.1-1) 4.9.1
       with this one, it prints -0

The only change I did was apt-get install gcc and then rebuilding Erlang.

BRs
Tomas
Attachment (int64nif.tar.gz): application/x-gzip, 1150 bytes
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
José Valim | 19 Jul 18:11 2014
Picon

Warning shows the wrong operator when useless operator is inside a useless contruction

Given the following code:

-module(foo).
-compile(export_all).

bar() ->
  [{foo, hello:world() == bar}],
  ok.

When compiled, it reports:

foo.erl:5: Warning: a term is constructed, but never used
foo.erl:5: Warning: use of operator '=:=' has no effect

The second warning is wrong. It must be refer to the operator '==' and not '=:='.

José Valim
Skype: jv.ptec
Founder and Lead Developer
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Du Felix | 18 Jul 07:57 2014
Picon

Syntax error: word unexpected (expecting ")" ) when cross compiling

Hi everyone.
      I did a cross compiling with the command:
      ./configure --host=arm-linux-gnueabif
      Duiring compilation, I got such error:

 === Entering application hipe
make[3]: Entering directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc'
 ERLC ../ebin/hipe_consttab.beam
/home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: 1:
/home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: Syntax error: word
unexpected (expecting ")")
make[3]: *** [../ebin/hipe_consttab.beam] Error 2
make[3]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc'
make[2]: *** [opt] Error 2
make[2]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe'
make[1]: *** [opt] Error 2
make[1]: Leaving directory `/home/dmy/App/otp_src_17.0/lib'
make: *** [secondary_bootstrap_build] Error 2

    When I went to /home/dmy/App/otp_src_17.0/lib/hipe/ebin, I didn't
find hipe_consttab.beam.

    I could successfully compiled a x86 erlang on my linux mint, but
got that error while cross compling.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs


Gmane