GNU bug report logs - #30193
crash in libotf

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30193 in the body.
You can then email your comments to 30193 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: The deadliest file in Emacs history
Date: Sun, 21 Jan 2018 17:54:25 +0800

Gentleman, I reveal to you the deadliest file in the history
of Emacs.

It is so deadly that it must be QP encoded, else, well,

Fatal error 11: Segmentation fault
Backtrace:
emacs[0x50a5fe]...
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11fb0)[0x7fc827b75fb0]
/usr/lib/x86_64-linux-gnu/libotf.so.0(OTF_drive_gpos_with_log+0x2a)[0x7fc828527a2a]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x24f2)[0x7fc8280e04f2]...

It is so deadly that once restored from QP, only emacs -nw can safely open it.

If you use X-windows, even doing "! cat"
(! runs the command dired-do-shell-command)
or just plain
$ emacs DEATH
will crash your emacs.
No matter if you do
# su - nobody
or even LC_ALL=C emacs ...
for the cleanest environment.

Oh yeah, here it is.

$ cat DEATH.qp
=E0=B2=B9=E0=B3=86=E0=B2=9A=E0=B3=8D=E0=B2=9A=E0=B3=81

It is so deadly that even in M-x shell,
just doing
$ qprint -d DEATH.qp
will fry your emacs.

emacs-version "25.2.2"
Debian emacs25 25.2+1-6

Message #8 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 Kenichi Handa <handa <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org
Subject: Re: bug#30193: The deadliest file in Emacs history
Date: Sun, 21 Jan 2018 18:23:47 +0200

> From: 積丹尼 Dan Jacobson
> 	<jidanni <at> jidanni.org>
> Date: Sun, 21 Jan 2018 17:54:25 +0800
> 
> Fatal error 11: Segmentation fault
> Backtrace:
> emacs[0x50a5fe]...
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x11fb0)[0x7fc827b75fb0]
> /usr/lib/x86_64-linux-gnu/libotf.so.0(OTF_drive_gpos_with_log+0x2a)[0x7fc828527a2a]
> /usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x24f2)[0x7fc8280e04f2]...

The crash seems to be inside the libotf/libm17n-flt library; CC'ing
Handa-san who may have comments on this.

Meanwhile, please make sure you have the latest versions of these
libraries installed.

FWIW, it doesn't crash here on MS-Windows, where these libraries are
not used by Emacs.

Thanks.

Message #11 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Kenichi Handa <handa <at> gnu.org>, 30193 <at> debbugs.gnu.org
Subject: Re: bug#30193: The deadliest file in Emacs history
Date: Mon, 22 Jan 2018 00:38:15 +0800

Package: emacs25
Version: 25.2+1-6
Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Versions of packages emacs25 depends on:
ii  emacs25-bin-common     25.2+1-6
ii  libacl1                2.2.52-3+b1
ii  libasound2             1.1.3-5
ii  libatk1.0-0            2.26.1-2
ii  libc6                  2.26.9000+20180108.401311cf-0experimental0
ii  libcairo-gobject2      1.15.8-3
ii  libcairo2              1.15.8-3
ii  libdbus-1-3            1.12.2-1
ii  libfontconfig1         2.12.6-0.1
ii  libfreetype6           2.8.1-1
ii  libgdk-pixbuf2.0-0     2.36.11-1
ii  libgif7                5.1.4-1
ii  libglib2.0-0           2.55.1-1
ii  libgnutls30            3.6.1-1
ii  libgomp1               8-20180110-1
ii  libgpm2                1.20.7-4
ii  libgtk-3-0             3.22.26-2
ii  libice6                2:1.0.9-2
ii  libjpeg62-turbo        1:1.5.2-2+b1
ii  libm17n-0              1.7.0-3+b2
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-16
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-16
ii  libotf0                0.9.13-3+b1
ii  libpango-1.0-0         1.40.14-1
ii  libpangocairo-1.0-0    1.40.14-1
ii  libpng16-16            1.6.34-1
ii  librsvg2-2             2.40.20-2
ii  libselinux1            2.7-2
ii  libsm6                 2:1.2.2-1+b3
ii  libtiff5               4.0.9-3
ii  libtinfo5              6.0+20171125-1
ii  libx11-6               2:1.6.4-3
ii  libx11-xcb1            2:1.6.4-3
ii  libxcb1                1.12-1
ii  libxfixes3             1:5.0.3-1
ii  libxft2                2.3.2-1+b2
ii  libxinerama1           2:1.1.3-1+b3
ii  libxml2                2.9.7+dfsg-1
ii  libxpm4                1:3.5.12-1
ii  libxrandr2             2:1.5.1-1
ii  libxrender1            1:0.9.10-1
ii  zlib1g                 1:1.2.8.dfsg-5

emacs25 recommends no packages.

Versions of packages emacs25 suggests:
ii  emacs25-common-non-dfsg  25.2+1-1

Message #16 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Kenichi Handa <handa <at> gnu.org>, 30193 <at> debbugs.gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Sun, 21 Jan 2018 13:37:44 -0500

Eli Zaretskii wrote:

> The crash seems to be inside the libotf/libm17n-flt library; CC'ing
> Handa-san who may have comments on this.
>
> Meanwhile, please make sure you have the latest versions of these
> libraries installed.

Still crashes with emacs-26 and latest m17n libs.
(Ie libotf 0.9.13 from 2012 and the m17n 1.8 RC from 2017)

Seems to have been reported multiple times to various downstreams,
who did nothing with the information. Eg

https://bugs.debian.org/826299
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1735167

Message #19 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: handa <handa <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Tue, 23 Jan 2018 23:30:24 +0900

In article <63zi57dpmv.fsf_-_ <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:

> Eli Zaretskii wrote:
> > The crash seems to be inside the libotf/libm17n-flt library; CC'ing
> > Handa-san who may have comments on this.
> >
> > Meanwhile, please make sure you have the latest versions of these
> > libraries installed.

> Still crashes with emacs-26 and latest m17n libs.
> (Ie libotf 0.9.13 from 2012 and the m17n 1.8 RC from 2017)

Sorry for being late.
I've just committed the attached fix to the CVS repository of libotf.
You can get the source by:
  % cvs -z3 -d:pserver:anonymous <at> cvs.savannah.nongnu.org:/sources/m17n co libotf

I am going to release the new version of libotf within a few weeks.

---
K. Handa
handa <at> gnu.org

2018-01-23  K. Handa  <handa <at> gnu.org>

	* src/otfopen.c (read_class_def): Handle the case of
	f.f1.GlyphCount and f.f2.ClassRangeCount being 0 gracefully.

--- otfopen.c.~1.65.~	2015-03-27 15:14:46.000000000 +0900
+++ otfopen.c	2018-01-23 22:40:04.740168815 +0900
@@ -1040,8 +1040,6 @@
 	= read_glyph_ids (otf, stream,
 			  (OTF_GlyphID **) &class->f.f1.ClassValueArray,
 			  0, -1);
-      if (! class->f.f1.GlyphCount)
-	return -1;
     }
   else if (class->ClassFormat == 2)
     {
@@ -1049,8 +1047,6 @@
 	= read_range_records (otf, stream,
 			      (OTF_RangeRecord **)
 			      &class->f.f2.ClassRangeRecord);
-      if (! class->f.f2.ClassRangeCount)
-	return -1;
     }
   else
     OTF_ERROR (OTF_ERROR_TABLE, " (Invalid format)");

Message #22 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: handa <handa <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Tue, 23 Jan 2018 22:31:43 -0500

Thanks, works for me.
Can anything be done to mitigate this in Emacs?
I expect it will be some time before the fixed libotf becomes the default
in some G/L distributions. Till then, an email can crash Emacs (I
assume) for someone who uses it to read mail.
Can there at least be a PROBLEMS entry?
Does this relate to bug#27836, 28110 at all?

Message #25 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: handa <handa <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Thu, 25 Jan 2018 18:23:45 +0900

In article <xqpo60gcf4.fsf <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:
> Thanks, works for me.

Thank you for confirming that!

> Can anything be done to mitigate this in Emacs?
> I expect it will be some time before the fixed libotf becomes the default
> in some G/L distributions. Till then, an email can crash Emacs (I
> assume) for someone who uses it to read mail.

At the moment, this problem occurs with NotoSerifKannada-Regular.ttf
and NotoSerifKannada-Bold.ttf. So, adding the following code will save
Emacs from crashing.

1. Check the version number of libotf in configure script.
2. Expose that version number to config.h.
3. In xfaces.c, if the version number is less than 0.9.16, initialize
   Vface_ignored_fonts to ("Noto Serif Kannada").

> Can there at least be a PROBLEMS entry?

We can advise (push "Noto Serif Kannada" face-ignored-fonts).

> Does this relate to bug#27836, 28110 at all?

#28110 is surely because of this bug, but as I can't reproduce #27836,
I'm not sure about it.

---
K. Handa
handa <at> gnu.org

Message #28 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <handa <at> gnu.org>
Cc: rgm <at> gnu.org, 30193 <at> debbugs.gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Thu, 25 Jan 2018 19:06:27 +0200

> From: handa <handa <at> gnu.org>
> Cc: eliz <at> gnu.org,  30193 <at> debbugs.gnu.org
> Date: Thu, 25 Jan 2018 18:23:45 +0900
> 
> 1. Check the version number of libotf in configure script.
> 2. Expose that version number to config.h.
> 3. In xfaces.c, if the version number is less than 0.9.16, initialize
>    Vface_ignored_fonts to ("Noto Serif Kannada").

Why not just add that font to face-ignored-fonts by default?

Thanks.

Message #31 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: handa <handa <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 30193 <at> debbugs.gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Fri, 26 Jan 2018 21:15:38 +0900

In article <83h8r9na0c.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> > 1. Check the version number of libotf in configure script.
> > 2. Expose that version number to config.h.
> > 3. In xfaces.c, if the version number is less than 0.9.16, initialize
> >    Vface_ignored_fonts to ("Noto Serif Kannada").

> Why not just add that font to face-ignored-fonts by default?

For those who build Emacs from source, isn't it better that they do not
have to change Emacs when they build Emacs with the new version of
libotf?

---
K. Handa
handa <at> gnu.org

Message #34 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <handa <at> gnu.org>
Cc: rgm <at> gnu.org, 30193 <at> debbugs.gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Fri, 26 Jan 2018 15:39:49 +0200

> From: handa <handa <at> gnu.org>
> Cc: rgm <at> gnu.org, 30193 <at> debbugs.gnu.org
> Date: Fri, 26 Jan 2018 21:15:38 +0900
> 
> In article <83h8r9na0c.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > > 1. Check the version number of libotf in configure script.
> > > 2. Expose that version number to config.h.
> > > 3. In xfaces.c, if the version number is less than 0.9.16, initialize
> > >    Vface_ignored_fonts to ("Noto Serif Kannada").
> 
> > Why not just add that font to face-ignored-fonts by default?
> 
> For those who build Emacs from source, isn't it better that they do not
> have to change Emacs when they build Emacs with the new version of
> libotf?

Why would they need ti change Emacs?  Is Noto Serif Kannada so
important that we cannot reasonably handle the Kannada script without
it?

Message #37 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: handa <handa <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Fri, 26 Jan 2018 22:56:34 -0500

handa wrote:

> 1. Check the version number of libotf in configure script.
> 2. Expose that version number to config.h.
> 3. In xfaces.c, if the version number is less than 0.9.16, initialize
>    Vface_ignored_fonts to ("Noto Serif Kannada").

Thanks, done in 2ce56c51a8.
It seems like a run-time test would be better.
(Will libotf 0.9.16 have an soname version bump?)

Message #40 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: handa <handa <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Sun, 28 Jan 2018 20:57:52 +0900

In article <ak1sicymx9.fsf <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:
> handa wrote:
> > 1. Check the version number of libotf in configure script.
> > 2. Expose that version number to config.h.

Sorry for that.  Directly checking the following macros of <otf.h> is
easier.

/* Version name of this library.  */
#define LIBOTF_VERSION "0.9.15"
/* Major version number.  */
#define LIBOTF_MAJOR_VERSION 0
/* Minor version number.  */
#define LIBOTF_MINOR_VERSION 9
/* Release (i.e. patch level) number.  */
#define LIBOTF_RELEASE_NUMBER 16

> > 3. In xfaces.c, if the version number is less than 0.9.16, initialize
> >    Vface_ignored_fonts to ("Noto Serif Kannada").

> Thanks, done in 2ce56c51a8.
> It seems like a run-time test would be better.
> (Will libotf 0.9.16 have an soname version bump?)

Yes.  The current library is libotf.so.0 (linked to libotf.so.0.0), but
the new one will be libotf.so.1 (linked to libotf.so.1.0.0).

---
K. Handa
handa <at> gnu.org

Message #43 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: handa <handa <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 30193 <at> debbugs.gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Sun, 28 Jan 2018 21:16:01 +0900

In article <83mv10lowq.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> > > Why not just add that font to face-ignored-fonts by default?
> > 
> > For those who build Emacs from source, isn't it better that they do not
> > have to change Emacs when they build Emacs with the new version of
> > libotf?

> Why would they need ti change Emacs?  Is Noto Serif Kannada so
> important that we cannot reasonably handle the Kannada script without
> it?

I can not tell how that font is important for Kannada users.

---
K. Handa
handa <at> gnu.org

Message #56 received at 30193-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 30193-done <at> debbugs.gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Fri, 02 Feb 2018 11:47:08 -0500

To summarize:
This is an issue in the libotf library that Emacs uses.
It will be fixed in a future libotf release.
In the meantime, it can be worked around in Emacs by adding
"Noto Serif Kannada" to face-ignored-fonts.

Message #64 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: handa <handa <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org, jidanni <at> jidanni.org, rgm <at> gnu.org
Subject: Re: bug#30193: crash in libotf
Date: Tue, 13 Feb 2018 08:25:12 +0900

In article <ncshajwd83.fsf <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:
> To summarize:
> This is an issue in the libotf library that Emacs uses.
> It will be fixed in a future libotf release.
> In the meantime, it can be worked around in Emacs by adding
> "Noto Serif Kannada" to face-ignored-fonts.

And, the new version of libotf (0.9.16, API version 1.0.0) has been
released along with the m17n library (1.8.0).

---
K. Handa
handa <at> gnu.org

Message #67 received at 30193 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: 30193 <at> debbugs.gnu.org
Subject: iOS, Telugu character
Date: Tue, 06 Mar 2018 06:50:20 +0800

Ah, reminds me of
http://www.thehindu.com/business/Industry/apple-acknowledges-serious-ios-bug-linked-to-telugu-character/article22772456.ece

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.