Package: libfontenc1
Version: 1:1.1.2-1
Hi,
during some updates / reinstalls of xfonts-unifont, I saw
Setting up xfonts-unifont (1:6.3.20140214-1) ...
Segmentation fault
Turned out that the inner command which segfaulted is:
mkfontscale -b -s -l -e /usr/share/fonts/X11/encodings -e
/usr/share/fonts/X11/
which crashes in some libfontenc1 code:
(gdb) run
Starting program: /usr/bin/mkfontscale -e .
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Breakpoint 1, FontEncIdentify (fileName=0x8050008 "./.")
at ../../src/encparse.c:906
906 {
(gdb) n
912 if((f = FontFileOpen(fileName))==NULL) {
(gdb)
915 encoding = parseEncodingFile(f, 1);
(gdb) s
parseEncodingFile (f=f@entry=0x80583c8, headerOnly=headerOnly@entry=1)
at ../../src/encparse.c:462
462 {
(gdb) n
465 unsigned short *enc=NULL;
(gdb)
467 unsigned i, first = 0xFFFF, last=0, encsize=0, namsize=0;
(gdb)
480 line = getnextline(f);
(gdb) s
getnextline (f=f@entry=0x80583c8) at ../../src/encparse.c:196
196 {
(gdb) n
198 c = FontFileGetc(f);
(gdb) n
196 {
(gdb) n
198 c = FontFileGetc(f);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xb7fb02b6 in getnextline (f=f@entry=0x80583c8) at ../../src/encparse.c:198
198 c = FontFileGetc(f);
(gdb)
Eventually found out that it works on a system with zlib1g 1.2.7.dfsg-13,
yet crashes on a system with 1:1.2.3.4.dfsg-3 .
A simple and successful test is to downgrade a (working) 1.2.7 system
via the 1.2.3.4 package (on my system there fortunately
were no packages installed which had a zlib1g Depends which disallowed that),
and then execute the well-known
mkfontscale -b -s -l -e /usr/share/fonts/X11/encodings -e
/usr/share/fonts/X11/
command again, which now ends up crashing rather than previously working.
Not sure what the policy of specifying newer versions is, though
(theoretically you could simply demand "> 1:1.2.3.4.dfsg-3"
to force an update from the non-compatible older zlib1g version,
or alternatively specifically demand ">= 1.2.7.dfsg-13"
which in this case has been proven to be working.
Finally, it's not quite known
what would constitute a sane libfontenc1 code implementation handling here
anyway - after all we're talking of a somewhat weird gzgetc()
of a gzopen() of filename "./.", i.e. the current-dir entry -
this probably would work for regular files but chooses to crash
for a dir entry (in the older zlib1g version, that is).
So perhaps libfontenc1 should be fixed (instead / as well)
to not do such shenanigans...
ii libfontenc1:i386 1:1.1.2-1 i386
X11 font encoding library
ii xfonts-utils 1:7.7+2 i386
X Window System font utility programs
ii zlib1g 1:1.2.3.4.dfsg-3 i386
compression library - runtime
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
