GNU bug report logs -
#17771
24.3.91; SIGSEGV in cleanup_vector
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Fri, 13 Jun 2014 09:14:02 UTC
Severity: normal
Tags: moreinfo
Merged with 16140,
16414,
17071,
17602
Found in versions 24.3.50, 24.3.91, 24.4.50
Fixed in version 24.3.93
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Tue, 17 Jun 2014 22:11:43 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/17/2014 05:41 PM, Stephen Berman wrote:
>
>> With fontconfig-debuginfo installed I get this:
>>
>> 33.61% emacs libc-2.18.so [.] __strchr_sse2
>> 15.77% emacs libfontconfig.so.1.8.0 [.] FcStrCaseWalkerNext.part.3
>
> OK. Next steps probably are:
>
> 1) Compile with '--with-x-toolkit=lucid --without-xft'
> and check how fast HELLO is displayed.
This failed to compile:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: image.o: undefined reference to symbol 'png_set_longjmp_fn@@PNG16_0'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: note: 'png_set_longjmp_fn@@PNG16_0' is defined in DSO /usr/lib64/libpng16.so.16 so try adding it to the linker command line
/usr/lib64/libpng16.so.16: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make[1]: Leaving directory `/data/steve/lib/emacs/emacs-24.4-lucid/src'
make: *** [src] Error 2
I have both libpng16 and libpng12 installed, since each is required by
different programs I use. Emacs built with Gtk+ links with libpng16
(which gtk3 requires), but with Lucid it apparently links with libpng12
if installed. It would be a PITA to uninstall libpng12 just to test
this. However, when I add `--without-png' to the configure line, then
Emacs with Lucid and without xft successfully builds. And with this
build it takes only about 3 seconds for HELLO to be displayed (with the
characters for which no suitable font could be found displayed as boxes
containing the hex codepoint).
Then I built with gtk3 and without xft, and here, too, it takes only
about 3 seconds for HELLO to be displayed.
> 2) Identify all font packages installed. I don't know about SuSE,
> but on my Fedora system all font packages are under 'User Interface/X'
> group, so "rpm -q -g 'User Interface/X'" shows all font packages
> (plus other X stuff, which may be filtered out by grepping for "noarch"
> packages). On my system, the following command:
>
> rpm -q -g 'User Interface/X' | grep noarch | grep font | wc -l
>
> shows 84 font packages.
>
> 3) Save list of packages obtained at step 2) and try to uninstall the most
> of font packages (but do not touch X core fonts - xorg-x11-fonts-* packages
> on my system). Next try to run "regular" (with Xft support enabled) Emacs
> and check whether font removal helps to speedup C-h h.
>
> 4) Reinstall all required fonts.
I took the opposite route, which was easier for me: I installed font
packages for all the languages that were displayed as hex codepoint
boxes (mainly South Asia and South East Asia). And lo and behold, now
with my normal build (including Xft support), it also takes only about 3
seconds for HELLO to be displayed (and there are no more hex codepoint
boxes)!
Prior to this, I had installed font packages for all languages in HELLO,
but still some characters in Tibetan were only displayed as hex
codepoint boxes. And it still took 30+ seconds for HELLO to be
displayed. But I found another font package for Tibetan which contained
the missing characters, and that made the difference. So probably the
lag was just due the searching through all fonts, as Andreas said.
Steve Berman
This bug report was last modified 10 years and 287 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.