error when tty-coding-system is utf-8

error when tty-coding-system is utf-8

[Miles Bader]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:



The following error seems to occur fairly often when I use "emacs -nw"
with the terminal-coding-system set to "utf-8"; it generally _isn't_
repeatable -- if I simply retry the user command that triggered it, it
usually succeeds the second time (and invoking the offending lisp call
manually usually succeeds too).

   Debugger entered--Lisp error: (args-out-of-range 5 19)
     utf-8-post-read-conversion(14)
     directory-files("/home/miles/" t "^\\.newsrc-slave-" t)
     gnus-master-read-slave-newsrc()
     gnus-group-get-new-news(nil)
     call-interactively(gnus-group-get-new-news)

It seems to most often happen in conjunction with Gnus.

Is there something else I can do to help track this down...?

Thanks,

-Miles



In GNU Emacs 22.0.50.23 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
 of 2005-05-26 on tc-1-100.kawasaki.gol.ne.jp
configured using `configure '--with-x-toolkit=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: ja_JP.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Message

Minor modes in effect:
  mml-mode: t
  auto-image-file-mode: t
  display-time-mode: t
  minibuffer-electric-default-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  recentf-mode: t
  variable-pitch-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  transient-mark-mode: t
  next-error-follow-minor-mode:  Fol
  abbrev-mode: t

Recent input:
C-n C-f C-n C-f C-n C-f C-f C-@ C-e ESC w SPC SPC C-x 
n L A C-a ESC f C-k RET n n C-x 1 C-u C-p SPC P N P 
C-x p C-n C-n C-n C-n C-n C-x n ESC n C-x p C-z C-z 
C-x n n n n L A C-g C-p C-p SPC C-n C-n SPC L a C-g 
L A C-a C-d ESC f C-k RET q g C-p C-x h ESC w C-x s 
RET RET C-y ESC < ESC x r e p o r t - e m a SPC RE
T

Recent messages:
Lower header (asbhirxeldft?): 
Lower header 'from' with match type (sefr?): 
Quit
Lower header (asbhirxeldft?): 
Loading debug...done
Entering debugger...
Mark set [2 times]
Parsing /home/miles/.mailrc... done
Mark set [2 times]
Loading emacsbug...done

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

Re: error when tty-coding-system is utf-8

[Luc Teirlinck]

Just a very wild guess, just in case: is there any possibility for a
timer to run during that code and mess up the match data?  I do not
know the code well enough to check whether it allows timers to run and
whether it uses the match data at some time after that.  The
unpredictability, combined with the args-out-of-range error reminds
me of a similarly completely unpredictable bug I recently fixed by
making Auto Revert restore the match data.

Sincerely,

Luc.

Re: error when tty-coding-system is utf-8

[Luc Teirlinck]

Is gnus-start-date-timer running when your problem occurs?
It runs article-update-date-lapsed which conducts a regexp search
without saving and restoring the match data, as it should.

I believe that the patch below is necessary, _regardless_ of whether
it solves your problem.  Does it?  There may be other similar problems
in gnus or elsewhere.  I could install the patch, if desired.  An
alternative is to automatically restore the match data around _all_
timers, but Richard pointed out that this would lead to
inefficiencies.

===File ~/gnus-art-diff=====================================
*** gnus-art.el	01 Jun 2005 10:13:45 -0500	1.74
--- gnus-art.el	02 Jun 2005 17:21:40 -0500	
***************
*** 3034,3053 ****
  
  (defun article-update-date-lapsed ()
    "Function to be run from a timer to update the lapsed time line."
!   (let (deactivate-mark)
!     (save-excursion
!       (ignore-errors
! 	(walk-windows
! 	 (lambda (w)
! 	   (set-buffer (window-buffer w))
! 	   (when (eq major-mode 'gnus-article-mode)
! 	     (let ((mark (point-marker)))
! 	       (goto-char (point-min))
! 	       (when (re-search-forward "^X-Sent:" nil t)
! 		 (article-date-lapsed t))
! 	       (goto-char (marker-position mark))
! 	       (move-marker mark nil))))
! 	 nil 'visible)))))
  
  (defun gnus-start-date-timer (&optional n)
    "Start a timer to update the X-Sent header in the article buffers.
--- 3034,3054 ----
  
  (defun article-update-date-lapsed ()
    "Function to be run from a timer to update the lapsed time line."
!   (save-match-data
!     (let (deactivate-mark)
!       (save-excursion
! 	(ignore-errors
! 	 (walk-windows
! 	  (lambda (w)
! 	    (set-buffer (window-buffer w))
! 	    (when (eq major-mode 'gnus-article-mode)
! 	      (let ((mark (point-marker)))
! 		(goto-char (point-min))
! 		(when (re-search-forward "^X-Sent:" nil t)
! 		  (article-date-lapsed t))
! 		(goto-char (marker-position mark))
! 		(move-marker mark nil))))
! 	  nil 'visible))))))
  
  (defun gnus-start-date-timer (&optional n)
    "Start a timer to update the X-Sent header in the article buffers.
============================================================

Re: error when tty-coding-system is utf-8

[Stefan Monnier]

> I believe that the patch below is necessary, _regardless_ of whether
> it solves your problem.  Does it?  There may be other similar problems
> in gnus or elsewhere.  I could install the patch, if desired.  An
> alternative is to automatically restore the match data around _all_
> timers, but Richard pointed out that this would lead to
> inefficiencies.

Maybe we could add debugging code somewhere so that timers which change the
match data get flagged (if you compile with debugging enabled)?


        Stefan

Re: error when tty-coding-system is utf-8

[Luc Teirlinck]

>From my previous message:

   Is gnus-start-date-timer running when your problem occurs?
   It runs article-update-date-lapsed which conducts a regexp search
   without saving and restoring the match data, as it should.

THe first sentence should have been:

Is article-lapsed-timer running...

Sincerely,

Luc.

Re: error when tty-coding-system is utf-8

[Miles Bader]

On 6/3/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> Is article-lapsed-timer running...

I don't know, but the variable `article-lapsed-timer' is nil.  Also
this error often happens before any article has been fetched (e.g.,
when entering a group for the first time).

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: error when tty-coding-system is utf-8

[Luc Teirlinck]

I forgot to look at at:

In GNU Emacs 22.0.50.23 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
 of 2005-05-26

I fixed Auto Revert mode 28 hours ago.  Do you use Auto Revert?  Then
the problem _might_ go away with updating your CVS.  Although, _if_ Auto
Revert can do it, then the gnus timer I referenced can do it too,
because it would mean that the involved functions do allow timers to
run at a time when they can mess up the match data.

Of course, timers can only do damage in functions that allow them to
run.  I do not know the functions you are using well enough to check
that.

But still, when your problems occur, what are the values of timer-list
and timer-idle-list?

Sincerely,

Luc.

Re: error when tty-coding-system is utf-8

[Luc Teirlinck]

Well, I could have checked from your minor mode list that you do not
use Auto Revert.  Of course there is no guarantee that your problem
has anything to do with timers.  It may still be worth while to check
timer-list and timer-idle-list when the problem occur.  If none of
these timers can mess up the match data, the problem definitely is not
caused by timers.  But if one of them does mess up the match data, it
is a pretty good candidate.

Sincerely,

Luc.