==15332== 2,500 (96 direct, 2,404 indirect) bytes in 6 blocks are definitely lost in loss record 324 of 342
==15332==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15332==    by 0x5748B9E: FontFileStartListFonts (in /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332==    by 0x5748C4A: FontFileStartListFontsAndAliases (in /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332==    by 0x42859A: nxdoListFontsAndAliases (NXdixfonts.c:1163)
==15332==    by 0x42C0E0: nxOpenFont (NXdixfonts.c:1541)
==15332==    by 0x43392E: ProcOpenFont (NXdispatch.c:902)
==15332==    by 0x434585: Dispatch (NXdispatch.c:482)
==15332==    by 0x40EF77: main (main.c:355)

FontFileStartListFonts[AndAliases]() allocates some private data. This
data is used by subsequent calls of FontFileListNextFontOrAlias() in a
loop. (Only) the last call to that function will free() the private
data and return with BadFontName.  FontFileListNextFontOrAlias() is
the only libXfont function that free()s the private data.

In nxagent the loop is exited as soon as a font exists both locally
and remote. Therefore the private data would never be free()d.

Solution: do not break the loop but store the first matching result
and let the loop run to the end, ignoring all following results.

Disadvantage: this can mean hundreds of extra iterations for
nothing. I have done no investigation of the time penalty this might
cause.

Unfortunately this is the only clean way I have found so far.

An unclean solution has also been implemented. It can be activated by
defining BREAK_XFONT_LOOP. In that case the private data is handled in
nxagent by taking assumptions about its structure (taken from the
libXfont source). That will break if libXfont changes its internal
handling of the private. Therefore it is discouraged.

An third alternative would be to drop using libXfont from the
system. Instead fork libXfont to the nx-libs tree, add some patches
link to that library statically.

Fixes ArcticaProject/nx-libs#586