Tuncer Ayaz | 17 Sep 19:23 2014
Picon

UBsan int overflows

On Wed, Sep 17, 2014 at 2:33 PM, Tuncer Ayaz wrote:
> Building OTP-17.3 with --enable-sanitizers=undefined, you can see
> the following during the build of lib/wx/examples/demo:
>  ERLC   ex_aui.beam
> beam/bif.c:2828:5: runtime error: signed integer overflow:
> 426141286 * 10 cannot be represented in type 'int'
>
> I thought this was also fixed.

More during dialyzer --build_plt:
beam/erl_process.c:9024:2: runtime error: signed integer overflow:
2147482509 + 2001 cannot be represented in type 'int'
beam/erl_process.c:4908:35: runtime error: signed integer overflow:
3984 * 625175 cannot be represented in type 'int'
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Tony Rogvall | 17 Sep 00:18 2014
Picon

try in shell

Hi!

Not sure how this is supposed to be, given that there is a shell function called catch_exception/1.

Running in 17.1 (approx)

> try throw(x) catch Class:Reason -> {Class,Reason} end.
{throw,x}

> try exit(2) catch Class:Reason -> {Class,Reason} end.          
* exception exit: 2

> try foo:bar() catch Class:Reason -> {Class,Reason} end.        
* exception error: undefined function erl_eval:expr/3

> try 1/0 catch Class:Reason -> {Class,Reason} end.       
* exception error: an error occurred when evaluating an arithmetic expression

> try (a=b) catch Class:Reason -> {Class,Reason} end.
* exception error: no match of right hand side value b

Putting the above try expression in a module:

-module(tryme).
-compile(export_all).

test1() ->
    try throw(x) catch Class:Reason -> {Class,Reason} end.

test2() ->
(Continue reading)

Alex Wilson | 12 Sep 14:23 2014
Picon

Segfault in asn1rt_nif:decode_ber_tlv

Hi erlang-bugs,

I've found a very interesting segmentation fault bug in 
asn1rt_nif:decode_ber_tlv.

A simple case to reproduce it: just type this at the shell:

   asn1rt_nif:decode_ber_tlv(<<"!",16#80>>).

It seems like whether or not the segmentation fault manifests varies a 
lot between different OS, compiler and OTP versions. So far I've 
reproduced it on:

  * R16B03-1 on Mac OSX Mavericks (clang)
  * R16B01 on OpenBSD 5.3-stable with gcc 4.2.1
  * R16B03-1 on Linux (Fedora) with gcc 4.8.3
  * R17B01 on OpenBSD 5.6-current with gcc 4.2.1
  * R17 developer build from "maint" branch as of last week, Mac OSX 
Mavericks (clang)

I also asked some random people in #erlang on freenode to try it out and 
they also reproduced the segfault using my test case.

Sometimes it doesn't segfault the first time around, but if you run it a 
few times at the shell it will do it eventually.

Backtrace from R17 maint on Mac OSX:

* thread #1: tid = 0x2410f5, 0x00007fff958db1aa 
libsystem_platform.dylib`_platform_memmove$VARIANT$Nehalem + 458, queue 
(Continue reading)

Shayan Pooya | 11 Sep 06:12 2014

Dialyzer's incorrect warning about opaque types

I have these two modules:

-module(has_opaque).
-export([init/0]).

-opaque state() :: queue:queue(erlang:timestamp()).
-export_type([state/0]).

-spec init()-> state().
init() ->
    queue:new().


and:

-module(use_opaque).
-export([init/0]).

-record(state, {t :: has_opaque:state()}).

init() ->
    {ok, #state{t = has_opaque:init()}}.


Dialyzer is giving me this error message:

"""
use_opaque.erl:7: The attempt to match a term of type 'undefined' | queue:queue({non_neg_integer(),non_neg_integer(),non_neg_integer()}) against the variable _ breaks the opaqueness of has_opaque:state()
"""

Compilation and invoking dialyzer:

compile:
        mkdir -p ebin
        erlc +debug_info -o ebin/ *.erl

dialyzer:
        dialyzer --get_warnings -Wno_return -Wunmatched_returns -Werror_handling -r ebin/ --plt ~/.dialyzer_plt


I get this error happens in Erlang 17.1 and 17.2.2 (on Linux). But Erlang R15B02 on OpenBSD did not complain.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Michael Truog | 10 Sep 20:49 2014
Picon

CT test crash

During a CT test shutdown (all tests were successful) I had CT crash 
with HTML output pending.  This happened with Erlang 17.0, so I am not 
sure if this has been fixed already.

Example output is below:

(...many of these ERROR REPORT terminated io format lines, full output 
at https://travis-ci.org/CloudI/CloudI/jobs/34936288...)

=ERROR REPORT==== 10-Sep-2014::17:56:01 ===

Error in process <0.356.1> on node 'test <at> localhost' with exit value:

{terminated,[{io,format,[<0.128.0>,"~ts",[[[[[10,60,100,105,118,32,99,108,97,115,115,61,34,101,114,114,111,114,95,108,111,103,103,101,114,34,62,60,98,62,42,42,42,32,83,121,115,116,101,109,32,114,101,112,111,114,116,32,100,117,114,105,110,103,32,"cloudi_service_quorum_SUITE",58,"end_per_suite",47,49,32,50,48,49,52,45,48,57,45,49,48,32,49,55,58,53,54,58,48,48,46,52,54,51,32,42,42,42,60,47,98,62]],"\n",["\n",61,"INFO 
REPORT",61,61,61,61,32,"10",45,"Sep",45,"...

=ERROR REPORT==== 10-Sep-2014::17:56:01 ===

Error in process <0.357.1> on node 'test <at> localhost' with exit value:

{terminated,[{io,format,[<0.128.0>,"~ts",[[[[[10,60,100,105,118,32,99,108,97,115,115,61,34,101,114,114,111,114,95,108,111,103,103,101,114,34,62,60,98,62,42,42,42,32,83,121,115,116,101,109,32,114,101,112,111,114,116,32,100,117,114,105,110,103,32,"cloudi_service_quorum_SUITE",58,"end_per_suite",47,49,32,50,48,49,52,45,48,57,45,49,48,32,49,55,58,53,54,58,48,48,46,52,54,52,32,42,42,42,60,47,98,62]],"\n",["\n",61,"INFO 
REPORT",61,61,61,61,32,"10",45,"Sep",45,"...

=ERROR REPORT==== 10-Sep-2014::17:56:01 ===

Error in process <0.38.0> on node 'test <at> localhost' with exit value:

{badarg,[{erlang,binary_to_term,[{error,does_not_exist}],[]},{ct_logs,get_cache_data,1,[{file,"ct_logs.erl"},{line,2607}]},{ct_logs,make_all_suites_index,1,[{file,"ct_logs.erl"},{line,2132}]},{ct_logs,close,2,[{file,"ct_logs.erl"},... 

Test run crashed! This could be an internal error - please report!

{badarg,[{erlang,binary_to_term,[{error,does_not_exist}],[]},

{ct_logs,get_cache_data,1,[{file,"ct_logs.erl"},{line,2607}]},

{ct_logs,make_all_suites_index,1,[{file,"ct_logs.erl"},{line,2132}]},

{ct_logs,close,2,[{file,"ct_logs.erl"},{line,170}]},

{ct_util,loop,3,[{file,"ct_util.erl"},{line,450}]}]}

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

Magnus Ottenklinger | 5 Sep 09:10 2014

Deadlocking application_controller using init:stop/1, 2

Hey List,

 

I sent  the following mail yesterday, but it seems that the mail was lost in space. Apologies if this reaches you twice.

 

Magnus

 

-----

 

We encountered a deadlock-problem with Erlang’s application mechanism in at least R16B01 and OTP 17. Namely, when using init:stop/0,1, a certain order of events can deadlock the application_controller, leaving the VM running. This can be mitigated using the Kernel application’s shutdown_timeout, but we think that this would just be a workaround and not a good fix.

 

Consider the following simple (and contrived) example:

 

-module(simple_app).

 

-behaviour(application).

 

-export([start/2,

         stop/1]).

 

start(_Type=normal, _Args) ->

    {ok,self()}.

 

stop(_State) ->

    application:load(crypto), %% yes, this is a bad idea.

    ok.

 

Compile and run the example:

 

1> make:all([load]).

up_to_date

2> application:start(simple).

ok

3> init:stop().

ok

4>

 

After this, application_controller will wait for simple_app to shutdown, whereas simple_app waits for the application_controller. Calls like application:which_applications/0 will time out.

 

Note that we encountered the problem above in a more complicated setting: while starting our system, we received init:stop/0,1 from user interaction with the shell. As some processes were still starting up (and calling application:load/1 in that process), we got stuck in a VM which could not stop itself using init:stop/0,1 anymore.

 

I propose that application:load/1,2 (and probably application:unload/1,2 as well) should return {error,shutting_down} if the application_controller is currently shutting down. For this, the application_controller should be able to reply to application:load_application/1 within its blocking receive in application:terminate/2.

 

Of course, as mentioned above, using shutdown_timeout would be possible, but that might crash applications unnecessarily when they would be able to shutdown nicely.

 

 

Regards, Magnus

 

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
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


Gmane