unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#17881: 24.4.50; decoding by emacs-mule hangs up
@ 2014-06-30  8:27 Katsumi Yamaoka
  2014-06-30 10:10 ` Dmitry Antipov
  0 siblings, 1 reply; 7+ messages in thread
From: Katsumi Yamaoka @ 2014-06-30  8:27 UTC (permalink / raw)
  To: 17881

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'





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17881: 24.4.50; decoding by emacs-mule hangs up
  2014-06-30  8:27 bug#17881: 24.4.50; decoding by emacs-mule hangs up Katsumi Yamaoka
@ 2014-06-30 10:10 ` Dmitry Antipov
  2014-06-30 15:40   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Dmitry Antipov @ 2014-06-30 10:10 UTC (permalink / raw)
  To: 17881; +Cc: Katsumi Yamaoka

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







^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17881: 24.4.50; decoding by emacs-mule hangs up
  2014-06-30 10:10 ` Dmitry Antipov
@ 2014-06-30 15:40   ` Eli Zaretskii
  2014-06-30 22:22     ` Katsumi Yamaoka
  2014-07-01 15:44     ` K. Handa
  0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-06-30 15:40 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17881, yamaoka

> 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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17881: 24.4.50; decoding by emacs-mule hangs up
  2014-06-30 15:40   ` Eli Zaretskii
@ 2014-06-30 22:22     ` Katsumi Yamaoka
  2014-07-01 15:44     ` K. Handa
  1 sibling, 0 replies; 7+ messages in thread
From: Katsumi Yamaoka @ 2014-06-30 22:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17881, Dmitry Antipov

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!





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17881: 24.4.50; decoding by emacs-mule hangs up
  2014-06-30 15:40   ` Eli Zaretskii
  2014-06-30 22:22     ` Katsumi Yamaoka
@ 2014-07-01 15:44     ` K. Handa
  2014-07-01 15:50       ` Eli Zaretskii
  2014-07-05 14:13       ` K. Handa
  1 sibling, 2 replies; 7+ messages in thread
From: K. Handa @ 2014-07-01 15:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17881, dmantipov, yamaoka

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)










^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17881: 24.4.50; decoding by emacs-mule hangs up
  2014-07-01 15:44     ` K. Handa
@ 2014-07-01 15:50       ` Eli Zaretskii
  2014-07-05 14:13       ` K. Handa
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-07-01 15:50 UTC (permalink / raw)
  To: K. Handa; +Cc: 17881, dmantipov, yamaoka

> 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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17881: 24.4.50; decoding by emacs-mule hangs up
  2014-07-01 15:44     ` K. Handa
  2014-07-01 15:50       ` Eli Zaretskii
@ 2014-07-05 14:13       ` K. Handa
  1 sibling, 0 replies; 7+ messages in thread
From: K. Handa @ 2014-07-05 14:13 UTC (permalink / raw)
  To: K. Handa; +Cc: dmantipov, 17881, yamaoka

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-07-05 14:13 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-30  8:27 bug#17881: 24.4.50; decoding by emacs-mule hangs up Katsumi Yamaoka
2014-06-30 10:10 ` Dmitry Antipov
2014-06-30 15:40   ` Eli Zaretskii
2014-06-30 22:22     ` Katsumi Yamaoka
2014-07-01 15:44     ` K. Handa
2014-07-01 15:50       ` Eli Zaretskii
2014-07-05 14:13       ` K. Handa

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).