headers
Peer Stritzinger | 1 May 2011 13:22
Picon

Dialyzer v2.2.0 crash

When running dialyzer like:

    $ dialyzer --src -c codec_can.erl

on the file codec_can.erl with the following contents (minimal code
snippet that shows the error):

    -module(codec_can).
    -compile(export_all).

    -record(can_pkt, {id, data, timestamp}).

    -spec recv(<<_:64,_:_*8>>,fun((_) -> any()),atom() | pid() |
{atom(),_}) -> any().
    recv(Packet, Recv_fun, Chan) ->
        P = decode(Packet),
        #can_pkt{id=Can_id, data=Can_data}=P,
        Recv_fun(P).

    -spec decode(<<_:64,_:_*8>>) ->
#can_pkt{id::<<_:11>>,data::binary(),timestamp::char()}.
    decode(<<_:12, Len:4, Timestamp:16,
             0:3, Id:11/bitstring, 0:18,
             Data:Len/binary, _/binary>>) ->
        #can_pkt{id=Id, data=Data, timestamp=Timestamp}.

I get the following error:

    $ dialyzer --src -c codec_can.erl
      Checking whether the PLT /home/peer/.dialyzer_plt is up-to-date... yes
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kostis Sagonas | 1 May 2011 16:49
Picon

Re: Dialyzer v2.2.0 crash

Peer Stritzinger wrote:
> When running dialyzer like:
> 
>     $ dialyzer --src -c codec_can.erl
> 
> on the file codec_can.erl with the following contents (minimal code
> snippet that shows the error):
> 
>     -module(codec_can).
>     -compile(export_all).
> 
>     -record(can_pkt, {id, data, timestamp}).
> 
>     -spec recv(<<_:64,_:_*8>>,fun((_) -> any()),atom() | pid() |
> {atom(),_}) -> any().
>     recv(Packet, Recv_fun, Chan) ->
>         P = decode(Packet),
>         #can_pkt{id=Can_id, data=Can_data}=P,
>         Recv_fun(P).
> 
>     -spec decode(<<_:64,_:_*8>>) ->
> #can_pkt{id::<<_:11>>,data::binary(),timestamp::char()}.
>     decode(<<_:12, Len:4, Timestamp:16,
>              0:3, Id:11/bitstring, 0:18,
>              Data:Len/binary, _/binary>>) ->
>         #can_pkt{id=Id, data=Data, timestamp=Timestamp}.
> 
> I get the following error:
>    ...  SNIP
(Continue reading)

Permalink | Reply | 4 comments |
headers
Peer Stritzinger | 1 May 2011 17:38
Picon

Re: Dialyzer v2.2.0 crash

On Sun, May 1, 2011 at 4:49 PM, Kostis Sagonas <kostis <at> cs.ntua.gr> wrote:
> Peer Stritzinger wrote:

> Thanks for your bug report!  It's indeed an error in the processing of
> binary types generated by typer which are then fed back to dialyzer.  I
> already have a patch ready that fixes this and will hopefully appear in
> OTP's dev branch pretty soon.

Great!

> If the other crash you get is in a function with a spec containing a type of
> the form <<_:N,_:_*M>>, don't bother minimizing the test case and sending a
> report.  Otherwise, please do -- perhaps just to me.

The other specs also contained this form, so its the same issue.

BTW: is it normal not to get any warnings when just doing --annotate
in typer and then dialyzer with no manually tweaked spec's (for
details see http://stackoverflow.com/questions/5849335/run-of-dialyzer-after-annotation-with-typer-did-not-show-any-warnings)?
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 1 comment |
headers
Kostis Sagonas | 1 May 2011 17:53
Picon

Re: Dialyzer v2.2.0 crash

Peer Stritzinger wrote:
> On Sun, May 1, 2011 at 4:49 PM, Kostis Sagonas <kostis <at> cs.ntua.gr> wrote:
>> Peer Stritzinger wrote:
> 
> BTW: is it normal not to get any warnings when just doing --annotate
> in typer and then dialyzer with no manually tweaked spec's 

Yes. In fact, typer is just a front end for dialyzer's basic type 
inference (i.e. without the warning identification component).

IMO, there is very little point in doing this if you do not intend to 
manually "massage" the specs that you get and provide more info for some 
of them.  Take a look at your previous program.  The fact that the two 
<<_:64,_:_*8>> types were referring to the same quantity could be 
expressed better if you introduced a type as in:

   -type packet() :: <<_:64,_:_*8>>,

Similarly for channel:

   -type channel() :: atom() | pid() |{atom(),_}.

and then the spec would already look better.  Also, dialyzer/typer has 
no info on what type of fun you intend to use in the second argument of 
function recv/3 but you do!  From the code it is clear that it takes 
#can_pkt{} record, so why don't you add appropriate types to its fields 
and introduce a type for it?

   -record(can_pkt, {id :: id(), data :: binary(), timestamp :: ts()}).
   -type can_pkt() :: #can_pkt{}.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kostis Sagonas | 2 May 2011 09:21
Picon

Re: Dialyzer v2.2.0 crash

Kostis Sagonas wrote:
> Peer Stritzinger wrote:
>> When running dialyzer like:
>>
>> ...
>>
>> I get the following error:
>>    ...  SNIP
> 
> Thanks for your bug report!  It's indeed an error in the processing of 
> binary types generated by typer which are then fed back to dialyzer.  I 
> already have a patch ready that fixes this and will hopefully appear in 
> OTP's dev branch pretty soon.

Since I had already a branch open which was fixing some other issue in 
erl_types.erl, I've decided to use that branch for including those fixes 
too.  I know it's not the proper way of doing things, but it's extremely 
cumbersome to maintain different versions of erl_types...

The changes that fix these are here:

   git fetch git://github.com/kostis/otp.git list_to_bitstring

The last commit fixes the issue reported by Peer.
The previous commits refer to erlang:list_to_bitstring/1.

Kostis
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henrik Nord | 2 May 2011 11:34
Favicon
Gravatar

Re: [erlang-patches] Dialyzer v2.2.0 crash

On 05/02/2011 09:21 AM, Kostis Sagonas wrote:
> Kostis Sagonas wrote:
>> Peer Stritzinger wrote:
>>> When running dialyzer like:
>>>
>>> ...
>>>
>>> I get the following error:
>>>    ...  SNIP
>>
>> Thanks for your bug report!  It's indeed an error in the processing 
>> of binary types generated by typer which are then fed back to 
>> dialyzer.  I already have a patch ready that fixes this and will 
>> hopefully appear in OTP's dev branch pretty soon.
>
> Since I had already a branch open which was fixing some other issue in 
> erl_types.erl, I've decided to use that branch for including those 
> fixes too.  I know it's not the proper way of doing things, but it's 
> extremely cumbersome to maintain different versions of erl_types...
>
> The changes that fix these are here:
>
>   git fetch git://github.com/kostis/otp.git list_to_bitstring
>
> The last commit fixes the issue reported by Peer.
> The previous commits refer to erlang:list_to_bitstring/1.
>
> Kostis
> _______________________________________________
> erlang-patches mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Ippolito | 3 May 2011 02:20
Gravatar

Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...]

I only see this error on Mac OS X. I have not been able to reproduce in Linux.

Here's an example, any number larger than 16#7ffffffffffffe00 will
cause this error.

Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
[async-threads:4] [hipe] [kernel-poll:true]

Eshell V5.8.3  (abort with ^G)
1> trunc(16#7ffffffffffffdff * 1.0).
9223372036854774784
2> trunc(16#7ffffffffffffdff * 1.0).
9223372036854774784
3> trunc(16#7ffffffffffffe00 * 1.0).
9223372036854775808
4> trunc(16#7ffffffffffffe00 * 1.0).
ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
0x19223372036854775808
5> trunc(16#7ffffffffffffe00 * 1.0).
ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
0x19223372036854775808
6> io:format("~s~n", [os:cmd("uname -a")]).
Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29
15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

Here's another example:

Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
[async-threads:4] [hipe] [kernel-poll:true]
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mikael Pettersson | 3 May 2011 10:04
Picon
Picon
Favicon

Re: Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...]

Bob Ippolito writes:
 > I only see this error on Mac OS X. I have not been able to reproduce in Linux.
 > 
 > Here's an example, any number larger than 16#7ffffffffffffe00 will
 > cause this error.
 > 
 > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
 > [async-threads:4] [hipe] [kernel-poll:true]
 > 
 > Eshell V5.8.3  (abort with ^G)
 > 1> trunc(16#7ffffffffffffdff * 1.0).
 > 9223372036854774784
 > 2> trunc(16#7ffffffffffffdff * 1.0).
 > 9223372036854774784
 > 3> trunc(16#7ffffffffffffe00 * 1.0).
 > 9223372036854775808
 > 4> trunc(16#7ffffffffffffe00 * 1.0).
 > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
 > 0x19223372036854775808
 > 5> trunc(16#7ffffffffffffe00 * 1.0).
 > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
 > 0x19223372036854775808
 > 6> io:format("~s~n", [os:cmd("uname -a")]).
 > Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29
 > 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
 > 
 > Here's another example:
 > 
 > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
 > [async-threads:4] [hipe] [kernel-poll:true]
(Continue reading)

Permalink | Reply | 6 comments |
headers
Loïc Hoguin | 3 May 2011 15:40
Picon
Gravatar

Specs missing or wrong in ssl, inet and gen_tcp

Hello,

Just forwarding a few issues I've encountered with type specs in ssl,
inet and gen_tcp. Hope you don't mind me sending all of them in a single
email.

I will try to send patches when I get some free time and would probably
benefit from any comment you might make here.

* https://github.com/erlang/otp/blob/dev/lib/ssl/src/ssl.erl

  * socketoption() is incomplete: it can also accept atoms like binary,
    list, inet6 or inet and also other kinds of tuples

  * socketoption() should probably depend on types defined
    in gen_tcp and inet

  * option() is defined as socketoption()|ssloption()|transportoption(),
    problem is socketoption() is defined as a list of options while
    others are tuples; socketoption() should be tuples too

* https://github.com/erlang/otp/blob/dev/lib/kernel/src/gen_tcp.erl

  * no specs at all, any plans on writing them? if not, any advice?

* https://github.com/erlang/otp/blob/dev/lib/kernel/src/inet.erl#L109

  * I'm assuming 'mode' is 'list' | 'binary' and not list() | binary()

Thanks.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bob Ippolito | 3 May 2011 16:18
Gravatar

Re: Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...]

On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson <mikpe <at> it.uu.se> wrote:
> Bob Ippolito writes:
>  > I only see this error on Mac OS X. I have not been able to reproduce in Linux.
>  >
>  > Here's an example, any number larger than 16#7ffffffffffffe00 will
>  > cause this error.
>  >
>  > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
>  > [async-threads:4] [hipe] [kernel-poll:true]
>  >
>  > Eshell V5.8.3  (abort with ^G)
>  > 1> trunc(16#7ffffffffffffdff * 1.0).
>  > 9223372036854774784
>  > 2> trunc(16#7ffffffffffffdff * 1.0).
>  > 9223372036854774784
>  > 3> trunc(16#7ffffffffffffe00 * 1.0).
>  > 9223372036854775808
>  > 4> trunc(16#7ffffffffffffe00 * 1.0).
>  > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
>  > 0x19223372036854775808
>  > 5> trunc(16#7ffffffffffffe00 * 1.0).
>  > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at
>  > 0x19223372036854775808
>  > 6> io:format("~s~n", [os:cmd("uname -a")]).
>  > Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29
>  > 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
>  >
>  > Here's another example:
>  >
>  > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4]
(Continue reading)

Permalink | Reply | 5 comments |

Gmane