8:45 p.m.
Hi,
It was a while since I attempted to catch this bug. I'm now getting
rather annoyed again, Enough to give a try once again.
* So what is the trouble?
Under XEmacs 21.5 dired sometimes gets the idea that the current
buffer actually is the *dired* buffer. This doesn't seem to happen
when running in '-vanilla'-mode. This could point in the direction of
some e-lisp-package doing bad things. Unfortunately it doesn't seem to
happen under 21.4.
Now this could seem like an innocent thing but after this has happened
XEmacs becomes very hard to work with. Example:
1. Create a buffer: /tmp/HI
2. Insert one line: hi
3. Buffer looks like
-------
hi
-------
4. Do dired-jump-back (C-x C-j). Buffer now looks like.
-------
/tmp:
hi
-------
And the error message: "dired-subdir-alist seems to be mangled" is
displayed. I guess the error message is because the buffer that dired
thinks is the dired buffer actually is the buffer I'm editing and thus
doesn't look like how a dired buffer should look like.
This is just one example of how it can be. Since obviously something
is badly broken very strange things can happen. Problems occur when
saving files or doing other operations that might involve dired
operations.
I have tried to debug this in e-lisp but I have failed. I need a good
debug idea. Anyone who has an idea how to track this down?
Yours
--
%% Mats
3:58 p.m.
Mats Lidell <matsl(a)xemacs.org> writes:
Under XEmacs 21.5 dired sometimes gets the idea that the current
buffer actually is the *dired* buffer. This doesn't seem to happen
when running in '-vanilla'-mode. This could point in the direction of
some e-lisp-package doing bad things. Unfortunately it doesn't seem to
happen under 21.4.
Now this could seem like an innocent thing but after this has happened
XEmacs becomes very hard to work with. Example:
1. Create a buffer: /tmp/HI
2. Insert one line: hi
3. Buffer looks like
-------
hi
-------
4. Do dired-jump-back (C-x C-j). Buffer now looks like.
-------
/tmp:
hi
-------
And the error message: "dired-subdir-alist seems to be mangled" is
displayed. I guess the error message is because the buffer that dired
thinks is the dired buffer actually is the buffer I'm editing and thus
doesn't look like how a dired buffer should look like.
This is just one example of how it can be. Since obviously something
is badly broken very strange things can happen. Problems occur when
saving files or doing other operations that might involve dired
operations.
I have tried to debug this in e-lisp but I have failed. I need a good
debug idea. Anyone who has an idea how to track this down?
Yours
--
%% Mats
Wow, so someone else has seen this too.
I first ran into this in 21.5.20 (ref: m37jiop84i.fsf(a)uh-oh.nvidia.com)
It seemed to be triggered by lazy-lock but I couldn't figure out
why. Eventually I tracked it down enough to generate the patch
below which avoided the problem without ever figuring out what
was really happening.
However, it seems to have been magically fixed in a recent
version 21.5 since I haven't needed to use the patch since at
least 21.5.24, and I've re-enabled lazy-lock (but with
lazy-lock-minimum-size increased from 10k to 50k).
Anyway, here's the patch. Maybe it will help you figure out
what's really going on.
*** process.el 2005/09/27 14:31:17 1.1
--- process.el 2005/09/27 14:33:37
***************
*** 133,139 ****
with SIGINT, then with SIGKILL if you quit again before the process exits.
Coding systems for the process are the same as for `start-process-internal'."
! (let (proc inbuf errbuf kill-inbuf kill-errbuf no-wait start end)
;; first set up an unwind-protect to clean everything up. this will:
;;
;; -- kill the process. (when we're not waiting for it to finish, we
--- 133,139 ----
with SIGINT, then with SIGKILL if you quit again before the process exits.
Coding systems for the process are the same as for `start-process-internal'."
! (let (curbuf proc inbuf errbuf kill-inbuf kill-errbuf no-wait start end)
;; first set up an unwind-protect to clean everything up. this will:
;;
;; -- kill the process. (when we're not waiting for it to finish, we
***************
*** 145,150 ****
--- 145,155 ----
;;
;; note that we need to be *very* careful in this code to handle C-g
;; at any point.
+
+ ;; save the current buffer for restore on exit in unwind sequence at bottom
+ ;; tbennett(a)nvidia.com 9/27/05
+ (setq curbuf (current-buffer))
+
(unwind-protect
(progn
;; first handle INFILE.
***************
*** 313,318 ****
--- 318,327 ----
;; outer unwind-protect forms, to make sure we always clean up.
(if (and inbuf kill-inbuf) (kill-buffer inbuf))
(if (and errbuf kill-errbuf) (kill-buffer errbuf))
+
+ ;; restore orig buffer. sometimes changed for reasons unclear to me...
+ (set-buffer curbuf)
+
(condition-case nil
(if (and proc (process-live-p proc)) (kill-process proc))
(error nil)))))
--
--tony
5:59 p.m.
Ar an tríú lá is fiche de mí Bealtaine, scríobh tbennett(a)nvidia.com:
> I have tried to debug this in e-lisp but I have failed. I need a
good
> debug idea. Anyone who has an idea how to track this down?
Mats, try updating to a version of the cc-mode package more recent than June
2005, and check if you still have the problem.
Wow, so someone else has seen this too.
I first ran into this in 21.5.20 (ref: m37jiop84i.fsf(a)uh-oh.nvidia.com)
It seemed to be triggered by lazy-lock but I couldn't figure out
why. Eventually I tracked it down enough to generate the patch
below which avoided the problem without ever figuring out what
was really happening.
The pre-idle-hook code doesn’t save-excursion, so any errors in it after the
current buffer has been changed result in the current buffer getting out of
sync. If you want to debug this sort of problem, try something like
replacing each function in pre-idle-hook with one which calls the function,
catching any error thrown, and backtracing on it.
--
Aidan Kehoe, http://www.parhasard.net/
8:45 p.m.
>>>> Aidan wrote:
Aidan> Mats, try updating to a version of the cc-mode package more
Aidan> recent than June 2005, and check if you still have the problem.
You mean a more recent version of cc-mode than what is in packages in
CVS? I try to keep up with the edge in CVS when it comes to 21.5 and
the packages.
Besides, I don't need to have cc-mode loaded to get the problem.
Yours
--
%% Mats
9:02 p.m.
Ar an tríú lá is fiche de mí Bealtaine, scríobh Mats Lidell:
>>>>> Aidan wrote:
Aidan> Mats, try updating to a version of the cc-mode package more
Aidan> recent than June 2005, and check if you still have the problem.
You mean a more recent version of cc-mode than what is in packages in
CVS?
No, if you have that version of packages, then you’re okay in terms of
being up to date.
I try to keep up with the edge in CVS when it comes to 21.5 and
the packages.
Besides, I don't need to have cc-mode loaded to get the problem.
What does C-h v pre-idle-hook RET give you before that test case? (Or F1 v
pre-idle-hook RET, if C-h isn’t bound to help-mode-map in your XEmacs.)
--
Aidan Kehoe, http://www.parhasard.net/
11:06 p.m.
>>>> Aidan wrote:
Aidan> What does C-h v pre-idle-hook RET give you ...
(font-lock-pre-idle-hook lazy-lock-pre-idle-fontify-windows)
Interesting... Am I getting this right. Problems in these functions
could be leaving the wrong buffer as current and thus ... OOPS!
Yours
--
%% Mats
8:58 a.m.
Ar an ceathrú lá is fiche de mí Bealtaine, scríobh Mats Lidell:
>>>>> Aidan wrote:
Aidan> What does C-h v pre-idle-hook RET give you ...
(font-lock-pre-idle-hook lazy-lock-pre-idle-fontify-windows)
Interesting... Am I getting this right. Problems in these functions
could be leaving the wrong buffer as current and thus ... OOPS!
Yes, exactly. save-excursion is the normal way to switch to another buffer
temporarily, and it switches the buffer back on error; the pre-idle-hook
functions don’t call it, because they need to be fast (they’re called very,
very frequently) and save-excursion involves allocating memory and is
generally not fast.
--
Aidan Kehoe, http://www.parhasard.net/
10:23 p.m.
>>>> Aidan wrote:
Aidan> Yes, exactly. save-excursion is the normal way to switch to
Aidan> another buffer temporarily, and it switches the buffer back on
Aidan> error; the pre-idle-hook functions don’t call it, because they
Aidan> need to be fast (they’re called very, very frequently) and
Aidan> save-excursion involves allocating memory and is generally not
Aidan> fast.
So I wrapped the two hooks in pre-idle-hook with a check-buffer-thing
like this:
(defun my-font-lock-pre-idle-hook ()
(let ((buf (current-buffer)))
(font-lock-pre-idle-hook)
(if (not (eq buf (current-buffer)))
(message "Wrong buffer back from font-lock-pre-idle-hook"))))
(defun my-lazy-lock-pre-idle-fontify-windows ()
(let ((buf (current-buffer)))
(lazy-lock-pre-idle-fontify-windows)
(if (not (eq buf (current-buffer)))
(message "Wrong buffer back from lazy-lock-pre-idle-fontify-windows"))))
And my message-buffer is now filled with "Wrong buffer back from
lazy-lock-pre-idle-fontify-windows" lines. So the problem is within
lazy-lock?
Yours
--
%% Mats
11:05 a.m.
Ar an cúigiú lá is fiche de mí Bealtaine, scríobh Mats Lidell:
(defun my-lazy-lock-pre-idle-fontify-windows ()
(let ((buf (current-buffer)))
(lazy-lock-pre-idle-fontify-windows)
(if (not (eq buf (current-buffer)))
(message "Wrong buffer back from lazy-lock-pre-idle-fontify-windows"))))
And my message-buffer is now filled with "Wrong buffer back from
lazy-lock-pre-idle-fontify-windows" lines. So the problem is within
lazy-lock?
Indeed, and some mode-specific fontification code and not the general
lazy-lock code, since the rest of us aren’t seeing the problem.
C-x 4 F lazy-lock-pre-idle-fontify-windows RET , then copy the function into
*scratch*, and put in a (message ) just after the "(while t " that says
which frame is being fontified and whether the current buffer is the initial
(current-buffer).
--
Aidan Kehoe, http://www.parhasard.net/
8:50 p.m.
>>>> Aidan wrote:
Aidan> C-x 4 F lazy-lock-pre-idle-fontify-windows RET , then copy the
Aidan> function into *scratch*, and put in a (message ) just after the
Aidan> "(while t " that says which frame is being fontified and
Aidan> whether the current buffer is the initial (current-buffer).
After doing that I went down the callstack and changed
(defun lazy-lock-maybe-fontify-frame (frame)
;; Fontify the given frame if we need to. We first check the
;; appropriate frame-modified-tick to avoid changing global state.
;(dp "fontify-frame %s" frame)
(let ((tick (frame-modified-tick frame))
(buf (current-buffer)) <--
(buf-name (buffer-name))) <--
;(dp tick)
(unless (eq tick (gethash frame lazy-lock-frame-modiff-cache))
(puthash frame tick lazy-lock-frame-modiff-cache)
;; We have to select the frame due to a bug in walk-windows in XEmacs
;; 21.4.
(with-selected-frame frame
(walk-windows #'lazy-lock-fontify-window 'no-minibuf frame))
(if (not (eq (current-buffer) buf)) (debug-print (concat
"Lazy-lock-maybe:" (frame-name) " Expected buf = " buf-name " but
got " (buffer-name)))) <--
)))
By inserting the lines marked with '<--' and using debug-print instead
of message. So now I can see things like:
Lazy-lock-maybe:XEmacs Expected buf = <BUFFER-NAME> but got
<NOT-SAME-BUFFER-NAME>
Conclusion: After walk-windows the buffer is changed. Now what!?
Yours
--
%% Mats
2:17 a.m.
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Aidan wrote:
Aidan> C-x 4 F lazy-lock-pre-idle-fontify-windows RET , then copy the
Aidan> function into *scratch*, and put in a (message ) just after the
Aidan> "(while t " that says which frame is being fontified and
Aidan> whether the current buffer is the initial (current-buffer).
After doing that I went down the callstack and changed
(defun lazy-lock-maybe-fontify-frame (frame)
;; Fontify the given frame if we need to. We first check the
;; appropriate frame-modified-tick to avoid changing global state.
;(dp "fontify-frame %s" frame)
(let ((tick (frame-modified-tick frame))
(buf (current-buffer)) <--
(buf-name (buffer-name))) <--
;(dp tick)
(unless (eq tick (gethash frame lazy-lock-frame-modiff-cache))
(puthash frame tick lazy-lock-frame-modiff-cache)
;; We have to select the frame due to a bug in walk-windows in XEmacs
;; 21.4.
(with-selected-frame frame
(walk-windows #'lazy-lock-fontify-window 'no-minibuf frame))
(if (not (eq (current-buffer) buf)) (debug-print (concat
"Lazy-lock-maybe:" (frame-name) " Expected buf = " buf-name " but
got " (buffer-name)))) <--
)))
By inserting the lines marked with '<--' and using debug-print instead
of message. So now I can see things like:
Lazy-lock-maybe:XEmacs Expected buf = <BUFFER-NAME> but got
<NOT-SAME-BUFFER-NAME>
Hi Mats,
why don't you post a sample log if you don't mind.
Including a timestamp would provide useful information too.
I use this to report loading of my init file:
(defun apa-loading-message (where)
"Print message including filename, user-defined string, and time
during loading.
The message is of the form:
Loading of FILE WHERE
at TIME-STRING TIME TIME-ZONE"
(if load-in-progress
(message "Loading of %s %s\nat %s %+.4d (%s)"
load-file-name
where
(current-time-string)
(/
(nth 0
(current-time-zone))
36)
(nth 1
(current-time-zone)))))
Conclusion: After walk-windows the buffer is changed. Now what!?
Yours
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
10:37 p.m.
>>>> APA wrote:
APA> why don't you post a sample log if you don't mind.
APA> Including a timestamp would provide useful information too.
OK. Here goes, now from *Message-Log* using message: (Analysis!? below)
----------------------------------------------------------------------
[...]
Loading dired...
Loading dired-mule...
Loading dired-mule...done
recent-files is already initialized.
Loading dired...done
Reading directory /home/matsl/work/...
Mon May 29 23:25:13 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:13 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:13 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:13 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:14 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
Mon May 29 23:25:15 2006 Lazy-lock-maybe:XEmacs Expected buf = work but got preIdleHook
No file on this line
[...]
----------------------------------------------------------------------
Explanation: I'm on the buffer preIdleHook (where I keep my code
fragments in trying to sort out this problem.) While there I do
{C-x d} (dired)
Dired is loaded and starts to read the directory /home/matsl/work
(where I keep the preIdleHook file). Now my buffer-check-code in
lazy-lock-maybe-fontify-frame starts to complain repeatedly because
when we go in into the function work is the current-buffer but going
out preIdleHook is current. (I can't account for why this is
repeated. It seems like work is found again and the lost again.
Finally preIdleHook is modified and dired thinks it is looking at a
dired buffer but finds no file, thus the final "No file on this line".
Yours
--
%% Mats
6535
days inactive
6542
days old
11 comments
4 participants
participants (4)
-
Adrian Aichner -
Aidan Kehoe -
The XEmacs Package Smoketest -
Tony Bennett