bug#17881: 24.4.50; decoding by emacs-mule hangs up

bug#17881: 24.4.50; decoding by emacs-mule hangs up

[Katsumi Yamaoka]

Hi,

Recently an old program that uses the `emacs-mule' coding system
hangs up.  Encoding seems ok, but decoding doesn't seem to return.
To reproduce this, please try:

(decode-coding-string "\222\244\242" 'emacs-mule)

This should return the Japanese letter "あ".
(Worse, killing the Emacs process is the only way to stop it on
 Cygwin because of bug#14553 -- "C-g doesn't break inf-loop".)

Thanks.

In GNU Emacs 24.4.50.1 (i686-pc-cygwin, GTK+ Version 3.10.7)
 of 2014-06-30 on localhost
Repository revision: 117445 michael.albinus@gmx.de-20140629183235-mpcng7hg27v7yryn
Windowing system distributor `The Cygwin/X Project', version 11.0.11501000
Configured using:
 `configure --verbose --with-x-toolkit=gtk3'

bug#17881: 24.4.50; decoding by emacs-mule hangs up

[Dmitry Antipov]

On 06/30/2014 12:27 PM, Katsumi Yamaoka wrote:

> Recently an old program that uses the `emacs-mule' coding system
> hangs up.  Encoding seems ok, but decoding doesn't seem to return.
> To reproduce this, please try:
>
> (decode-coding-string "\222\244\242" 'emacs-mule)
>
> This should return the Japanese letter "あ".
> (Worse, killing the Emacs process is the only way to stop it on
>   Cygwin because of bug#14553 -- "C-g doesn't break inf-loop".)

Quick bisection shows that this was introduced in r117432.

Dmitry

bug#17881: 24.4.50; decoding by emacs-mule hangs up

[Eli Zaretskii]

> Date: Mon, 30 Jun 2014 14:10:25 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: Katsumi Yamaoka <yamaoka@jpl.org>
> 
> On 06/30/2014 12:27 PM, Katsumi Yamaoka wrote:
> 
> > Recently an old program that uses the `emacs-mule' coding system
> > hangs up.  Encoding seems ok, but decoding doesn't seem to return.
> > To reproduce this, please try:
> >
> > (decode-coding-string "\222\244\242" 'emacs-mule)
> >
> > This should return the Japanese letter "あ".
> > (Worse, killing the Emacs process is the only way to stop it on
> >   Cygwin because of bug#14553 -- "C-g doesn't break inf-loop".)
> 
> Quick bisection shows that this was introduced in r117432.

Fixed in trunk revision 117451.

bug#17881: 24.4.50; decoding by emacs-mule hangs up

[Katsumi Yamaoka]

On Mon, 30 Jun 2014 18:40:41 +0300, Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Mon, 30 Jun 2014 14:10:25 +0400
>> From: Dmitry Antipov <dmantipov@yandex.ru>
>> Cc: Katsumi Yamaoka <yamaoka@jpl.org>
>>
>> On 06/30/2014 12:27 PM, Katsumi Yamaoka wrote:
>>
>>> Recently an old program that uses the `emacs-mule' coding system
>>> hangs up.  Encoding seems ok, but decoding doesn't seem to return.
>>> To reproduce this, please try:
>>>
>>> (decode-coding-string "\222\244\242" 'emacs-mule)
>>>
>>> This should return the Japanese letter "あ".
>>> (Worse, killing the Emacs process is the only way to stop it on
>>>   Cygwin because of bug#14553 -- "C-g doesn't break inf-loop".)
>>
>> Quick bisection shows that this was introduced in r117432.

> Fixed in trunk revision 117451.

The old program in question now works.  Thank you!

bug#17881: 24.4.50; decoding by emacs-mule hangs up

[K. Handa]

In article <83wqby4d8m.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> Fixed in trunk revision 117451.

Thank you for the quick fix!
But, considering the usage of coding->charbuf, I think the
following fix is better.  It always allocates 16 units more
in coding->charbuf.  So, as far as it doesn't reach
MAX_CHARBUF_SIZE, decoding routines never stop by
insufficient coding->charbuf.  I'm going to install it as
soon as I finish several tests.

=== modified file 'src/coding.c'
--- src/coding.c	2014-06-28 13:38:36 +0000
+++ src/coding.c	2014-07-01 15:27:35 +0000
@@ -7266,13 +7266,17 @@
 }
 
 #define MAX_CHARBUF_SIZE 0x4000
-#define MIN_CHARBUF_SIZE 0x10
+/* How many units decoding functions expect in coding->charbuf at
+   most.  Currently, decode_coding_emacs_mule expects the following
+   size, and that is the largest value.  */
+#define MAX_CHARBUF_EXTRA_SIZE ((MAX_ANNOTATION_LENGTH * 3) + 1)
 
 #define ALLOC_CONVERSION_WORK_AREA(coding, size)		\
   do {								\
-    int units = ((size) > MAX_CHARBUF_SIZE ? MAX_CHARBUF_SIZE	\
-		 : (size) < MIN_CHARBUF_SIZE ? MIN_CHARBUF_SIZE	\
-		 : size);					\
+    int units = (size) + MAX_CHARBUF_EXTRA_SIZE;		\
+								\
+    if (units > MAX_CHARBUF_SIZE)				\
+      units = MAX_CHARBUF_SIZE;					\
     coding->charbuf = SAFE_ALLOCA ((units) * sizeof (int));	\
     coding->charbuf_size = (units);				\
   } while (0)

bug#17881: 24.4.50; decoding by emacs-mule hangs up

[Eli Zaretskii]

> From: handa@gnu.org (K. Handa)
> Cc: dmantipov@yandex.ru, 17881@debbugs.gnu.org, yamaoka@jpl.org
> Date: Wed, 02 Jul 2014 00:44:59 +0900
> 
> In article <83wqby4d8m.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Fixed in trunk revision 117451.
> 
> Thank you for the quick fix!
> But, considering the usage of coding->charbuf, I think the
> following fix is better.  It always allocates 16 units more
> in coding->charbuf.  So, as far as it doesn't reach
> MAX_CHARBUF_SIZE, decoding routines never stop by
> insufficient coding->charbuf.  I'm going to install it as
> soon as I finish several tests.

Thanks.

bug#17881: 24.4.50; decoding by emacs-mule hangs up

[K. Handa]

In article <87tx71dqx0.fsf@gnu.org>, handa@gnu.org (K. Handa) writes:

> In article <83wqby4d8m.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > Fixed in trunk revision 117451.

> Thank you for the quick fix!
> But, considering the usage of coding->charbuf, I think the
> following fix is better.  It always allocates 16 units more
> in coding->charbuf.  So, as far as it doesn't reach
> MAX_CHARBUF_SIZE, decoding routines never stop by
> insufficient coding->charbuf.  I'm going to install it as
> soon as I finish several tests.

I've just committed that change to the trunk.

---
Kenichi Handa
handa@gnu.org