XEmacs 21.5 and dired-gets-current-buffer-wrong bug

[tbennett at nvidia.com]

Mats Lidell <matsl at 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 at 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 at 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