[erlang-questions] Dialyzer crash

[Kostis Sagonas]

Alexey Romanov wrote:
> I've got this error when trying to run dialyzer (from R14B) on my project:
> 
> aromanov@REDACTED:~/workspace/gm-controller$ dialyzer --verbose
> --build_plt --output_plt dialyzer/gmcontroller_1.plt -r ebin
>   Compiling some key modules to native code... done in 1m41.75s
>   Creating PLT dialyzer/gmcontroller_1.plt ...
> =ERROR REPORT==== 8-Oct-2010::17:29:59 ===
> ... SNIP
> 
> dialyzer: Analysis failed with error:
> {function_clause,[{erl_types,inf_tuples_in_sets,4},
>                   {erl_types,inf_tuple_sets,4},
>                   {erl_types,inf_tuple_sets,3},
>                   {erl_types,inf_union,5},
>                   {erl_types,t_inf_lists_strict,4},
>                   {erl_types,t_inf,3},
>                   {dialyzer_typesig,solve_one_c,...},
>                   {dialyzer_typesig,...}]}
> Last messages in the log cache:
>   Typesig analysis for SCC: [{server_protocol_client,handle_call,3}]
>   Typesig analysis for SCC: [{config,read_file,1}]
>   Typesig analysis for SCC: [{config,merge_with_file,2}]
>   Typesig analysis for SCC: [{config,read,1}]
>   Typesig analysis for SCC: [{device,hardware_capabilities_test,0}]
>   Typesig analysis for SCC: [{gmc_root_sup,init,1}]
>   Typesig analysis for SCC: [{gmcontroller,start,2}]
>   Typesig analysis for SCC: [{messages,recv,3}]
>   Typesig analysis for SCC: [{messages,send,4}]
>   Typesig analysis for SCC: [{server_protocol_client,do_request_play_lists,5}]
> 
> 
> I am not sure in what order the log messages are given, but both
> handle_call and do_request_play_lists specifications look fine to me
> and are accepted by the compiler:
> 
> -spec do_request_play_lists(target_id(), [p_date()], key(), ivec(), ivec()) ->
> 		{ivec(), ivec()}.
> 
> -spec handle_call(any(), pid(), state()) -> handle_call_return(state()).
> 
> --verbose option (which is listed in dialyzer --help) also doesn't
> seem particularly useful here (there is quite a bit of time before the
> error comes up). Any ideas how the error can be fixed?

The error can be fixed by identifying a minimal set of modules that 
trigger the same crash and sending it to me -- off list is probably 
preferable.  I might be wrong of course, but I suspect this is related 
to the handle_call_return(state()) type which is a parameterized one -- 
we have not seen many uses of those.

Kostis