···<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
pgpvO970_OE1_.pgp
Description: PGP signature
