Emacs 22 lockup + CCL: Quited.

Emacs 22 lockup + CCL: Quited.

[Kim F. Storm]

I'm using an Emacs 22 built a few days ago, and today it has started
to lockup for long periods of time (many seconds) and even hitting C-g
does not bring it back to life.  

But after some time has elapsed, it inserts "CCL:Quitted" in the buffer,
and it becomes responsive again...

I've seen it happen two or three times in connection with replying
to a message in Gnus.  I don't known how to reproduce it.



In GNU Emacs 22.1.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2008-03-05 on kfs-lx
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40300000
configured using `configure  '--with-gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  cua-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
SPC o n SPC n o n - s h i f t e d SPC m o v e m e n 
t . . <down> <return> C-d <up> <return> C-d <up> <return> 
I SPC c a n SPC m a k e SPC a SPC p a <backspace> r 
o p <backspace> <backspace> <backspace> a t c h SPC 
t o SPC s <backspace> d o SPC t h i s . . . <return> 
<up> C-c C-c <down> <down> SPC <down> <down> <down> 
m e m a c s - d e v e - <backspace> l @ g n u i <backspace> 
 o r g <down> E m a c s SPC 2 2 SPC p r o b l e m 
: SPC C-v M-y M-y M-y M-y M-y M-y M-y M-y M-y M-y M-y 
M-y <C-left> <C-left> <C-left> M-d l o c k u p SPC 
+ SPC C-d C-d <down> <down> <down> <down> <down> <down> 
<up> <return> T o d a y SPC I ' v e SPC s t a r t e 
d SPC t o SPC s e e SPC E m a c s SPC 2 2 SPC l o c 
k u p SPC f o r SPC l o n g SPC p e r i o d s SPC o 
f SPC t i m e , <return> a n d SPC t h e n <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> a f t e r SPC w h i c h SPC 
I SPC h i t SPC M-x r e p o r t - e m <tab> <return> 
<return> n <up> C-a <S-down> <S-down> C-x <timeout> 
M-x r e p o r t - e m a <tab> <return>

Recent messages:
250 Ok: queued as 629C0FAC039
221 Bye
Wrote /home/kfs/Mail/mail/sent/6226
Sending...done
Opening nntp server on news.gmane.org...done
Mark set
Loading emacsbug...done
Buffer has unsaved changes; reinitialize it and discard them? (y or n) 
sendmail-user-agent-compose: Message aborted
Undo!


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 lockup + CCL: Quited.

[Chong Yidong]

"Kim F. Storm" <storm@cua.dk> writes:

> I'm using an Emacs 22 built a few days ago, and today it has started
> to lockup for long periods of time (many seconds) and even hitting C-g
> does not bring it back to life.  
>
> But after some time has elapsed, it inserts "CCL:Quitted" in the buffer,
> and it becomes responsive again...
>
> I've seen it happen two or three times in connection with replying
> to a message in Gnus.  I don't known how to reproduce it.
>
> In GNU Emacs 22.1.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
>  of 2008-03-05 on kfs-lx

I'm assuming you're using this Emacs, built on the 5th of March, five
days ago.  Did you only start seeing this problem today, or did it
happen shortly after you built and started using it?

I don't see anything in the branch changelogs that could plausibly be
linked to this.

Re: Emacs 22 lockup + CCL: Quited.

[Glenn Morris]

Chong Yidong wrote:

> "Kim F. Storm" <storm@cua.dk> writes:
>
>> I'm using an Emacs 22 built a few days ago, and today it has started
>> to lockup for long periods of time (many seconds) and even hitting C-g
>> does not bring it back to life.  
>>
>> But after some time has elapsed, it inserts "CCL:Quitted" in the buffer,
>> and it becomes responsive again...

Sounds like this issue from the trunk in September?

http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01314.html

Re: Emacs 22 lockup + CCL: Quited.

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> "Kim F. Storm" <storm@cua.dk> writes:
>>
>>> I'm using an Emacs 22 built a few days ago, and today it has started
>>> to lockup for long periods of time (many seconds) and even hitting C-g
>>> does not bring it back to life.  
>>>
>>> But after some time has elapsed, it inserts "CCL:Quitted" in the buffer,
>>> and it becomes responsive again...
>
> Sounds like this issue from the trunk in September?
>
> http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01314.html

Was the fix mentioned in this message the following one?

2007-09-14  Kenichi Handa  <handa@m17n.org>

        * xterm.c (handle_one_xevent): Skip decoding if nbytes is zero.

Handa-san, could you check if a similar fix is needed for the branch?


*** xterm.c	2007/09/10 21:25:32	1.956
--- xterm.c	2007/09/14 04:11:26	1.957
***************
*** 6538,6579 ****
  	       gives us composition information.  */
  	    coding.composing = COMPOSITION_DISABLED;
  
! 	    for (i = 0; i < nbytes; i++)
  	      {
! 		STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
! 	      }
  
! 	    {
! 	      /* Decode the input data.  */
! 	      int require;
! 	      unsigned char *p;
! 
! 	      require = decoding_buffer_size (&coding, nbytes);
! 	      p = (unsigned char *) alloca (require);
! 	      coding.mode |= CODING_MODE_LAST_BLOCK;
! 	      /* We explicitly disable composition handling because
! 		 key data should not contain any composition sequence.  */
! 	      coding.composing = COMPOSITION_DISABLED;
! 	      decode_coding (&coding, copy_bufptr, p, nbytes, require);
! 	      nbytes = coding.produced;
! 	      nchars = coding.produced_char;
! 	      copy_bufptr = p;
! 	    }
  
! 	    /* Convert the input data to a sequence of
! 	       character events.  */
! 	    for (i = 0; i < nbytes; i += len)
! 	      {
! 		if (nchars == nbytes)
! 		  c = copy_bufptr[i], len = 1;
! 		else
! 		  c = STRING_CHAR_AND_LENGTH (copy_bufptr + i,
! 					      nbytes - i, len);
! 		inev.ie.kind = (SINGLE_BYTE_CHAR_P (c)
! 			      ? ASCII_KEYSTROKE_EVENT
! 			      : MULTIBYTE_CHAR_KEYSTROKE_EVENT);
! 		inev.ie.code = c;
! 		kbd_buffer_store_event_hold (&inev.ie, hold_quit);
  	      }
  
  	    /* Previous code updated count by nchars rather than nbytes,
--- 6538,6580 ----
  	       gives us composition information.  */
  	    coding.composing = COMPOSITION_DISABLED;
  
! 	    if (nbytes > 0)
  	      {
! 		/* Decode the input data.  */
! 		int require;
! 		unsigned char *p;
  
! 		for (i = 0; i < nbytes; i++)
! 		  {
! 		    STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
! 		  }
  
! 		require = decoding_buffer_size (&coding, nbytes);
! 		p = (unsigned char *) alloca (require);
! 		coding.mode |= CODING_MODE_LAST_BLOCK;
! 		/* We explicitly disable composition handling because
! 		   key data should not contain any composition sequence.  */
! 		coding.composing = COMPOSITION_DISABLED;
! 		decode_coding (&coding, copy_bufptr, p, nbytes, require);
! 		nbytes = coding.produced;
! 		nchars = coding.produced_char;
! 		copy_bufptr = p;
! 
! 		/* Convert the input data to a sequence of
! 		   character events.  */
! 		for (i = 0; i < nbytes; i += len)
! 		  {
! 		    if (nchars == nbytes)
! 		      c = copy_bufptr[i], len = 1;
! 		    else
! 		      c = STRING_CHAR_AND_LENGTH (copy_bufptr + i,
! 						  nbytes - i, len);
! 		    inev.ie.kind = (SINGLE_BYTE_CHAR_P (c)
! 				    ? ASCII_KEYSTROKE_EVENT
! 				    : MULTIBYTE_CHAR_KEYSTROKE_EVENT);
! 		    inev.ie.code = c;
! 		    kbd_buffer_store_event_hold (&inev.ie, hold_quit);
! 		  }
  	      }
  
  	    /* Previous code updated count by nchars rather than nbytes,

Re: Emacs 22 lockup + CCL: Quited.

[Johan Bockgård]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> "Kim F. Storm" <storm@cua.dk> writes:
>>
>>> I'm using an Emacs 22 built a few days ago, and today it has started
>>> to lockup for long periods of time (many seconds) and even hitting C-g
>>> does not bring it back to life.  
>>>
>>> But after some time has elapsed, it inserts "CCL:Quitted" in the buffer,
>>> and it becomes responsive again...
>
> Sounds like this issue from the trunk in September?
>
> http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01314.html

The problem I saw was simply that the error message was inserted into
the current buffer.  Emacs is admittedly sluggish when operating on this
huge text, but I didn't consider that in itself to be a bug.  And I
don't think that the patch changed anything in this respect (but let's
hear what Handa says).

-- 
Johan Bockgård

Re: Emacs 22 lockup + CCL: Quited.

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> "Kim F. Storm" <storm@cua.dk> writes:
>
>> I'm using an Emacs 22 built a few days ago, and today it has started
>> to lockup for long periods of time (many seconds) and even hitting C-g
>> does not bring it back to life.  
>>
>> But after some time has elapsed, it inserts "CCL:Quitted" in the buffer,
>> and it becomes responsive again...
>>
>> I've seen it happen two or three times in connection with replying
>> to a message in Gnus.  I don't known how to reproduce it.
>>
>> In GNU Emacs 22.1.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
>>  of 2008-03-05 on kfs-lx
>
> I'm assuming you're using this Emacs, built on the 5th of March, five
> days ago.  Did you only start seeing this problem today, or did it
> happen shortly after you built and started using it?
>
> I don't see anything in the branch changelogs that could plausibly be
> linked to this.

I've only seen it yesterday - I was working from home, using my
home Laptop as an X-server for Emacs 22 running on my work PC.

I do this all the time, and haven't seen the problem before.
One difference though is that yesterday I had to use a somewhat 
slower Internet connection due to problems on the primary link.

Is there some timeout in the CCL engine?
Maybe some bad interaction with X server timeouts?

One other difference is that the Emacs 22 session had previously
failed to deliver mail (trying to use the SMTP server on the primary
ISP) - I then switched to using the SMTP server on the secondary ISP.

But the lockup happens while I'm writing a message - not when sending it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 lockup + CCL: Quited.

[Kenichi Handa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=ISO-2022-JP-2, Size: 2547 bytes --]

In article <yoij7igaoq8p.fsf@remote2.student.chalmers.se>, bojohan+news@dd.chalmers.se (Johan Bockg^[$(D+)^[(Brd) writes:

> Glenn Morris <rgm@gnu.org> writes:
> > Chong Yidong wrote:
> >
>>> "Kim F. Storm" <storm@cua.dk> writes:
>>> 
>>>> I'm using an Emacs 22 built a few days ago, and today it has started
>>>> to lockup for long periods of time (many seconds) and even hitting C-g
>>>> does not bring it back to life.  
>>>> 
>>>> But after some time has elapsed, it inserts "CCL:Quitted" in the buffer,
>>>> and it becomes responsive again...
> >
> > Sounds like this issue from the trunk in September?
> >
> > http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01314.html

> The problem I saw was simply that the error message was inserted into
> the current buffer.  Emacs is admittedly sluggish when operating on this
> huge text, but I didn't consider that in itself to be a bug.  And I
> don't think that the patch changed anything in this respect (but let's
> hear what Handa says).

Yes, the change installed was just to avoid the unnecessary
call of CCL.  If you reads a huge file with CCL-based coding
system, Emacs still runs a CCL code long time, and when you
hit C-g, Emacs reports it that way (i.e. insert "CCL:
Quited" in a buffer).  I agree that it's not a good way of
reporting that decoding was quitted.

I've just installed this change for EMACS_22_BASE.  Could
someone please improve the way of reporting `quit'?

---
Kenichi Handa
handa@ni.aist.go.jp

Index: fileio.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/fileio.c,v
retrieving revision 1.580.2.11
retrieving revision 1.580.2.12
diff -c -r1.580.2.11 -r1.580.2.12
*** fileio.c	7 Mar 2008 15:42:30 -0000	1.580.2.11
--- fileio.c	10 Mar 2008 12:19:35 -0000	1.580.2.12
***************
*** 4632,4639 ****
--- 4632,4650 ----
      {
        if (CODING_MAY_REQUIRE_DECODING (&coding))
  	{
+ 	  if (coding.type == coding_type_ccl)
+ 	    coding.spec.ccl.decoder.quit_silently = 1;
  	  code_convert_region (PT, PT_BYTE, PT + inserted, PT_BYTE + inserted,
  			       &coding, 0, 0);
+ 	  if (coding.type == coding_type_ccl)
+ 	    coding.spec.ccl.decoder.quit_silently = 0;
+ 	  if (coding.result == CODING_FINISH_INTERRUPT)
+ 	    {
+ 	      /* Fixme: It is better that we report that the decoding
+ 		 was interruppted by the user, and the current buffer
+ 		 contents doesn't reflect the file correctly.  */
+ 	      Fsignal (Qquit, Qnil);
+ 	    }
  	  inserted = coding.produced_char;
  	}
        else

Re: Emacs 22 lockup + CCL: Quited.

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> Yes, the change installed was just to avoid the unnecessary
> call of CCL.  If you reads a huge file with CCL-based coding
> system, Emacs still runs a CCL code long time, and when you
> hit C-g, Emacs reports it that way (i.e. insert "CCL:
> Quited" in a buffer).  I agree that it's not a good way of
> reporting that decoding was quitted.

So why would CCL decoding kick in in the middle of replying
to a mail message?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 lockup + CCL: Quited.

[Stefan Monnier]

>> Yes, the change installed was just to avoid the unnecessary
>> call of CCL.  If you reads a huge file with CCL-based coding
>> system, Emacs still runs a CCL code long time, and when you
>> hit C-g, Emacs reports it that way (i.e. insert "CCL:
>> Quited" in a buffer).  I agree that it's not a good way of
>> reporting that decoding was quitted.

> So why would CCL decoding kick in in the middle of replying
> to a mail message?

Hopefully, with Handa's change, you'll be able to get a backtrace via
signal-on-quit next time you hit the problem.


        Stefan