On 12 July 2016 at 13:25, David Kastrup <[email protected]> wrote: > Mojca Miklavec <[email protected]> writes: > >> So here it goes ... >> >> (gdb) r test.ly >> Starting program: >> /Applications/LilyPond.app/Contents/Resources/bin/lilypond test.ly >> warning: Tried to remove a non-existent library: >> /usr/lib/libstdc++.6.0.9.dylib >> warning: Tried to remove a non-existent library: >> /usr/lib/libstdc++.6.0.9.dylib >> ... >> warning: Tried to remove a non-existent library: >> /usr/lib/libstdc++.6.0.9.dylib >> Reading symbols for shared libraries >> +++++++++..+........................................................................................................................................... >> done >> Reading symbols for shared libraries . done >> GNU LilyPond 2.19.45 >> Reading symbols for shared libraries . done >> ^C >> Program received signal SIGINT, Interrupt. >> 0x988f6e38 in memmove$VARIANT$sse3x () >> (gdb) backtrace >> #0 0x988f6e38 in memmove$VARIANT$sse3x () >> #1 0x00b54b8f in cf2_glyphpath_moveTo () >> Previous frame inner to this frame (gdb could not unwind past this frame) > > Bah. The innermost frame is just a memory copy, and the next one some > font operation. cf2 would be the Freetype2 library, Werner? > >> second attempt: >> >> ^C >> Program received signal SIGINT, Interrupt. >> 0x99885a62 in read$NOCANCEL$UNIX2003 () >> (gdb) backtrace >> #0 0x99885a62 in read$NOCANCEL$UNIX2003 () >> #1 0x9891aee6 in __sread () >> #2 0x9891af0e in _sread () >> #3 0x9891b465 in __srefill1 () >> #4 0x9891bece in _fseeko () >> #5 0x9891b9a2 in fseek () > > Completely useless (at least up to there, something else coming > afterwards?), just a file seek. We did already know that it was going > through a lot of files. > > This does not really help us figure out what part of _LilyPond_ is > responsible for triggering the font cache rebuild. > >> Let me know if there is anything else I could try or if I should >> collect more "statistics". > > Some backtrace that actually starts somewhere in LilyPond would be good. > So that would be a backtrace that actually ends somewhere in "main".
I probably need to recompile lilypond with debug info then. Here are some more (useless?) traces: #0 0x99885a62 in read$NOCANCEL$UNIX2003 () #1 0x9891aee6 in __sread () #2 0x9891af0e in _sread () #3 0x9891b465 in __srefill1 () #4 0x9891c189 in __fread () #5 0x9891c01f in fread () #6 0x00b34045 in FT_Stream_EnterFrame () #0 0x00b40bb6 in TT_Load_Simple_Glyph () #1 0x00b47e62 in load_truetype_glyph () #2 0x03818640 in ?? () Previous frame inner to this frame (gdb could not unwind past this frame) #0 0x9988571e in open$NOCANCEL$UNIX2003 () #1 0x99884a98 in open () #2 0x988c62d9 in fopen () #3 0x00b2e6ae in FT_Stream_Open () >> This time the first lilypond run took 2,5 minutes to complete >> (apparently I had additional problems with swap yesterday that >> prolonged the process to almost 10 minutes). > > 2.5 minutes is still not great. I'm wondering why LilyPond needs to > entertain its own version of the font cache. I don't see any viable alternative other than rewriting some portions to use the native system library calls to get information about fonts. Mojca _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
