[luatex] mkluatexfontdb devours memory

[Philipp Gesang]

···<date: 2013-05-11, Saturday>···<from: Arno Trautmann>···

> Élie Roux wrote:
> >On 11/05/2013 16:46, Akira Kakuto wrote:
> >>Hi all,
> >>
> >>>Confirmed. I have the same problem with svn revision 4635 on x64
> >>>Arch. The TL binary is revision 4627, maybe do a debug build of
> >>>that one?
> >>
> >>You havt to apply the attached patch to kpathsea/texmf.cnf
> >>in the luatex svn before the build.
> >
> >Many thanks!
> 
> Thank you, too, Akira. With the patched version from Élie I now can
> compile fine and the formats are build.
> 
> >Arno, if you replace source/texk/kpathsea/texmf.cnf with the attached
> >file and recompile the binary, can you build the formats?
> 
> Yes. Running now
> 
> valgrind -v --leak-check=full texlua luaotfload-tool.lua 2
> 
> results in the output here:
> 
> http://justpaste.it/2lq6
> 
> with the summary:
> 
> ==29474== LEAK SUMMARY:
> ==29474==    definitely lost: 11,667 bytes in 539 blocks
> ==29474==    indirectly lost: 2,638 bytes in 92 blocks
> ==29474==      possibly lost: 0 bytes in 0 blocks
> ==29474==    still reachable: 5,524,891 bytes in 257,399 blocks
> ==29474==         suppressed: 0 bytes in 0 blocks
> ==29474== Reachable blocks (those to which a pointer was found) are
> not shown.
> ==29474== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==29474==
> ==29474== ERROR SUMMARY: 38 errors from 38 contexts (suppressed: 2 from 2)
> --29474--
> --29474-- used_suppression:      2 dl-hack3-cond-1
> ==29474==
> ==29474== ERROR SUMMARY: 38 errors from 38 contexts (suppressed: 2 from 2)
> 
> I guess ERROR is not good? …
> 
> I now tried again
> 
> luaotfload-tool --update --force --verbose=5 --log=stdout
> 
> but still it fills the whole memory up. The first time it stopped at
> the font Loma.ttf, so I blacklisted it, but now the last output I
> get is
> 
> luaotfload | db: loading font “/usr/share/fonts/TTF/Loma.ttf”
> luaotfload | db: ignoring blacklisted font “/usr/share/fonts/TTF/Loma.ttf”
> 
> So maybe a font after this one is a problem?

Yes, that is possible. The logging mechanism uses texio.*() and
the line printing the culprit font may not have been flushed at
that moment. It happened before.

>                                              But as I don't see any
> system in the order in which the fonts are loaded, I cannot say
> which one is loaded next …

I’ll upload a new version to CTAN inside an hour. It’ll provide
the --dry-run switch that will print the loading order.

Thanks for testing
Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://tug.org/pipermail/luatex/attachments/20130511/e76fbd51/attachment.bin>