Dialyzer: report call to undefined function

Tobias Lindahl <>
Sat May 20 13:01:40 CEST 2006

Ulf Wiger (AL/EAB) wrote:
> Vlad Dumitrescu wrote:
>>I think it would be useful if Dialyzer would also report 
>>calls to undefined or unexported functions. I often spell 
>>names wrong :-)
> Agreed. Our local patched version of Dialyzer does this.
> I think the initial assumption was that there are other 
> tools that do this for you, but we felt that since Dialyzer
> has the information, it might as well present it.
>>[Aside] How difficult would it be to make Dialyzer work
> Difficult - alas.

I can confirm this :-(

> We played with this quite a lot, since we have lots and lots
> of erlang code in a fairly slow version control system.
> Running Dialyzer on the ClearCase repository took about an 
> hour per subsystem...
> What we did was to prune the PLT, removing all modules 
> that depended on the ones being analysed.
> But the approach that finally became useful was to incorporate
> Dialyzer in our simulated environment, and running it on all
> code currently loaded (we use -embedded code loading). This,
> together with some optimizations in the call graph etc., 
> brought the time for a full system analysis down to 3 minutes
> (running in the background). Fredrik Svahn, one of our 
> section managers, did some really good work there.

I guess this time is for re-analyzing a small increment - not for 
analyzing the whole system that took several hours before? Otherwise I 
would be really interested in what is happening.

Unfortunatly, this approach is dependent on having a running system 
where Dialyzer can run in the background. We have been playing with the 
idea of keeping checksums for modules and pruning the plt based on this. 
In conjunction with keeping plt:s for subsystems and keeping track of 
dependencies, we shoud be able to squeeze the times quite a bit, but it 
has not been very high on our TODO-list.

>>I mean that it should be possible to build the internal 
>>tables by adding and removing modules from them, without 
>>having to reread everything else. The analysis needs a global 
>>approach, but for a large project, reading the files takes 
>>the large chunk of the time.
> There are some pitfalls, though, and there is also the risk
> that incremental analysis will give a false sense of security.

Yes, especially since warnings from the modules that was analyzed 
earlier will not be given again in the new analysis. In a perfect world 
all discrepancies are handled right away, but in my experience this is 
not what actually happens.

Tobias (speaking as one who spent significant time trying to muscle 
Dialyzer into existence. ;-)
> /Ulf (speaking as one who spent significant time trying to 
> muscle in incremental analysis into Dialyzer. ;-)

More information about the erlang-questions mailing list