GNU bug report logs - #17881
24.4.50; decoding by emacs-mule hangs up

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 17881 in the body.
You can then email your comments to 17881 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: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; decoding by emacs-mule hangs up
Date: Mon, 30 Jun 2014 17:27:34 +0900

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 <at> gmx.de-20140629183235-mpcng7hg27v7yryn
Windowing system distributor `The Cygwin/X Project', version 11.0.11501000
Configured using:
 `configure --verbose --with-x-toolkit=gtk3'

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: 17881 <at> debbugs.gnu.org
Cc: Kenichi Handa <handa <at> gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#17881: 24.4.50; decoding by emacs-mule hangs up
Date: Mon, 30 Jun 2014 14:10:25 +0400

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 17881 <at> debbugs.gnu.org, yamaoka <at> jpl.org
Subject: Re: bug#17881: 24.4.50; decoding by emacs-mule hangs up
Date: Mon, 30 Jun 2014 18:40:41 +0300

> Date: Mon, 30 Jun 2014 14:10:25 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> Cc: Katsumi Yamaoka <yamaoka <at> 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.

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17881 <at> debbugs.gnu.org, Dmitry Antipov <dmantipov <at> yandex.ru>
Subject: Re: bug#17881: 24.4.50; decoding by emacs-mule hangs up
Date: Tue, 01 Jul 2014 07:22:29 +0900

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

>> Date: Mon, 30 Jun 2014 14:10:25 +0400
>> From: Dmitry Antipov <dmantipov <at> yandex.ru>
>> Cc: Katsumi Yamaoka <yamaoka <at> 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!

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

From: handa <at> gnu.org (K. Handa)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17881 <at> debbugs.gnu.org, dmantipov <at> yandex.ru, yamaoka <at> jpl.org
Subject: Re: bug#17881: 24.4.50; decoding by emacs-mule hangs up
Date: Wed, 02 Jul 2014 00:44:59 +0900

In article <83wqby4d8m.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> 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)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <at> gnu.org (K. Handa)
Cc: 17881 <at> debbugs.gnu.org, dmantipov <at> yandex.ru, yamaoka <at> jpl.org
Subject: Re: bug#17881: 24.4.50; decoding by emacs-mule hangs up
Date: Tue, 01 Jul 2014 18:50:27 +0300

> From: handa <at> gnu.org (K. Handa)
> Cc: dmantipov <at> yandex.ru, 17881 <at> debbugs.gnu.org, yamaoka <at> jpl.org
> Date: Wed, 02 Jul 2014 00:44:59 +0900
> 
> In article <83wqby4d8m.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> 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.

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

From: handa <at> gnu.org (K. Handa)
To: handa <at> gnu.org (K. Handa)
Cc: eliz <at> gnu.org, dmantipov <at> yandex.ru, 17881 <at> debbugs.gnu.org, yamaoka <at> jpl.org
Subject: Re: bug#17881: 24.4.50; decoding by emacs-mule hangs up
Date: Sat, 05 Jul 2014 23:13:57 +0900

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

> In article <83wqby4d8m.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> 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 <at> gnu.org

Previous Next

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