[erlang-questions] code path cache vs atom table

[Per Hedeland]

Hi,

I guess this is more or less moot, since the code path cache has been
removed in 19, but maybe this anecdote can be useful info for someone
else that is still using it in older versions. We had a customer report
that the emulator crashed due to filling up the atom table, and after a
significant amount of debugging and brainstorming (and a bit of luck) we
found that the culprit was this nugget in code_server:

filter_mods([File|Rest], Where, Exts, Dir, Cache) ->
    Ext = filename:extension(File),
    Root = list_to_atom(filename:rootname(File, Ext)),
    case lists:keyfind(Ext, 2, Exts) of
        {Type, _} ->
            Key = {Type,Root},
            ...

This code has the effect that whenever the cache is rebuilt (happens
e.g. if a requested module isn't found I believe), an atom is created
(if it didn't already exist) for every file/directory in every directory
of the code path. Doesn't sound too bad... - until you consider that "."
is in the path by default, combined with the possibility that the
emulator is started in /tmp on a busy server. The atom table was full of
entries like

tmp6CA6Yt
tmp1R7aPK
tmp8WBvWp
tmpDKQd39
tmpPKCyaf
tmpkijfAQ
tmpofoTOG

- the typical result of calls to libc mktemp(3) & friends. Obviously the
atoms remained even if the files had been removed since the previous
cache rebuild - it took 2-3 weeks of running time from start to crash.

If the list_to_atom() call had been 2 lines further down where it should
have been, the problem wouldn't have occurred...

--Per Hedeland