tramp and diff-mode results in Emacs crash

tramp and diff-mode results in Emacs crash

[Dale Sedivec]

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

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.4.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2006-03-07 on hs20-bc1-6.build.redhat.com
configured using `configure  --build=i386-redhat-linux --host=i386-redhat-linux --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-pop --with-sound'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  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

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

When I edit a diff file on a remote machine with TRAMP, and then ask
diff-mode to convert context->unified format, Emacs begins behaving
very strangely and eventually crashes.

Steps to reproduce:
1. Put foo.rej (included below) on a remote machine that you can get
   to with TRAMP
2. Start Emacs: /usr/bin/emacs-x -q
3. M-:
4. M-( require 'tramp M-) RET
5. C-x C-f
6. C-a C-k /10.0.1.169:foo.rej RET
7. Note that I do not enter any passwords since TRAMP uses SSH and I'm
   using RSA authentication with ssh-agent
7. Press U to do context->unified, or use the mouse to click the
   context->unified function under the Diff menu

Expected results:
Diff is converted from context to unified format.

Observed results:
Sometimes nothing, but sometimes I'll get a single letter "S" in the
minibuffer (as if someone had done (message "S")).

After executing context->unified, lots of things in Emacs stop
working:
- C-x C-c doesn't do anything; pressing C-x will display C-x in the
  minibuffer
- C-x b does nothing: no change in the minibuffer, and pressing RET in
  an effort to switch to another buffer (i.e., *scratch*) does nothing
- Menu options don't do anything, though you can drop down menus and
  see the menu that results from clicking '?' on the toolbar
- Sometimes buffer switching works, sometimes it doesn't
- Selecting the unified->context option from the Diff menu with the
  mouse often produces the expected text in the minibuffer, though the
  foo.rej buffer sees no changes
- Selecting context->unified from the menu or pressing U doesn't do
  anything
- I'm unable to change the buffer at all

I can't say all of the above happen 100% of the time.  The exact
effects you see are sometimes different, and the exact way it crashes
differs (abort, segmentation fault), but it always crashes.

The most reliable way I've found to cause Emacs to crash: simply hold
down "U" to repeatedly attempt context->unified.  Also, clicking every
option on the Diff menu, top to bottom, over and over until it crashes
usually works.

I have several core files laying around.  Here's a backtrace from one:

#0  0x00644410 in ?? ()
#1  0xbfeb7048 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00000006 in ?? ()
#4  0x001ce2d6 in kill () from /lib/libc.so.6
#5  0x080df149 in fatal_error_signal (sig=6) at emacs.c:354
#6  0x00644420 in ?? ()
#7  0x00000006 in ?? ()
#8  0x00000033 in ?? ()
#9  0x00000000 in ?? ()

That one isn't very helpful, I think.  Later on I managed this one:

#0  0x080f9e1e in set_buffer_internal_1 (b=0x87bcbf8) at buffer.c:1642
#1  0x080616bf in with_echo_area_buffer (w=0x0, which=Variable "which" is not available.
) at xdisp.c:6299
#2  0x080618cc in current_message () at xdisp.c:6735
#3  0x080618fc in push_message () at xdisp.c:6770
#4  0x0810de1e in Fdo_auto_save (no_message=405431388, current_only=405431340)
    at fileio.c:5493
#5  0x080dd69d in shut_down_emacs (sig=11, no_x=0, stuff=405431340)
    at emacs.c:1883
#6  0x080df0da in fatal_error_signal (sig=11) at emacs.c:341
#7  0x00382420 in _XimTransConf ()
#8  0x080fb09f in Fset_buffer (buffer=1217315056) at buffer.c:1800
#9  0x080fe05a in Fcombine_after_change_execute () at insdel.c:2102
#10 0x080fde17 in signal_after_change (charpos=2486, lendel=1, lenins=0)
    at insdel.c:2017
#11 0x08100354 in del_range_both (from=2486, from_byte=2486, to=Variable "to" is not available.
)
    at insdel.c:1671
#12 0x08064396 in message_dolog (m=0x8195073 "", nbytes=0, nlflag=1,
    multibyte=0) at xdisp.c:5732
#13 0x080643e6 in message_log_maybe_newline () at xdisp.c:5630
#14 0x080645ba in setup_echo_area_for_printing (multibyte_p=1) at xdisp.c:6444
#15 0x0814b940 in write_string_1 (data=0xbfdb3d3a "", size=-1,
    printcharfun=405431388) at print.c:573
#16 0x080e4bb0 in cmd_error_internal (data=1485750404, context=0xbfdb3d3a "")
#17 0x080e4ca3 in cmd_error (data=1485750404) at keyboard.c:1132
#18 0x0813a73c in internal_condition_case (bfun=0x80ec220 <command_loop_1>,
    handlers=405527684, hfun=0x80e4bf0 <cmd_error>) at eval.c:1257
#19 0x080e47a3 in command_loop_2 () at keyboard.c:1245
#20 0x0813a832 in internal_catch (tag=405489268,
    func=0x80e4780 <command_loop_2>, arg=405431340) at eval.c:1030
#21 0x080e48e7 in command_loop () at keyboard.c:1224
#22 0x080e498e in recursive_edit_1 () at keyboard.c:950
#23 0x080e4aab in Frecursive_edit () at keyboard.c:1006
#24 0x080de49b in main (argc=2, argv=0xbfdb4424, envp=Cannot access memory at address 0x484985c0
) at emacs.c:1547
#25 0x006d14e4 in ?? () from /lib/libc.so.6
#26 0x00000002 in ?? ()
#27 0xbfdb4424 in ?? ()
#28 0xbfdb4430 in ?? ()
#29 0x0019678b in _dl_fixup () from /lib/ld-linux.so.2
#30 0x0804f571 in ?? ()

But the fact that some of the core files look like that first one, and
the others all looked different from one another (at a glance)
suggests to me that these backtraces aren't very useful anyway.
(Though I'll gladly produce them until I'm blue in the face if I'm
wrong and they are helpful.)

I've used the Emacs Lisp debugger to step through
diff-context->unified.  When the function is byte compiled (I assume
that's what it means when some of the things I'm stepping through are
"byte-code") the last thing I see in the debugger is (match-string 4);
hitting 's' to execute that makes the debugger window disappear and
now I'm in the weird state described above.  The same thing happened
when I evaluated the file with a (debug) added, but there it exited
before evaluating (if (match-beginning 2) ...).

I have consistently reproduced this on:
- Fedora Core (FC) 5 GNU Linux i386 with Emacs in X Windows (same
  Emacs I'm using to write this bug report)
- Same FC 5 i386 machine with non-X Windows Emacs (i.e.,
  /usr/bin/emacs-nox in gnome-terminal (think xterm))
- A different FC 5 i386 machine, freshly updated and rebooted
- An Ubuntu 6.10 (Edgy) i386 running in VMware, Emacs in X Windows

So that's two physically separate machines, three different "OS"
installs.

Additional details on the first FC5 machine mentioned above:
$ rpm -q glibc
glibc-2.4-11
$ uname -a
Linux censored.internal.name 2.6.18-1.2257.fc5smp #1 SMP Fri Dec 15 16:33:51 EST 2006 i686 athlon i386 GNU/Linux
$ egrep defconst.*tramp-version /usr/share/emacs/site-lisp/tramp/trampver.el
(defconst tramp-version "2.0.49"

I also (first, in fact) saw this behavior first using TRAMP 2.1.8.

SELinux is off (permissive).  I believe Fedora has a few other
security features, like kind of segment randomization.  (I also
believe I could recreate the crash with "setarch i386 -R
/usr/bin/emacs -q" so as to disable that randomization.)

I have only been able to reproduce this crash with the diff file
below, though admittedly I didn't try very hard to reproduce it with
other diff files.  I'm not actually positive this is a "diff file":
it's the result of a failed patch(1) attempt.  Please note that
accessing this same file locally (i.e., not through TRAMP) works just
fine, though: I can do the context->unified conversion without any
problems.

######################################################################
# foo.rej:
######################################################################

***************
*** 3,27 ****
  use strict;
  
  $max_servers = 2;             # number of pre-forked children (2..15 is common)
- $daemon_user  = 'amavis';     # (no default;  customary: vscan or amavis)
- $daemon_group = 'amavis';     # (no default;  customary: vscan or amavis)
  
  $mydomain = 'yourdomain.tld'; # a convenient default for other settings
  
- $MYHOME   = '/var/amavisd';   # a convenient default for other settings
  $TEMPBASE = "$MYHOME/tmp";    # working directory, needs to be created manually
  $ENV{TMPDIR} = $TEMPBASE;     # environment variable TMPDIR
- $QUARANTINEDIR = '/var/virusmails';
  
  # Blowfish encryption key file (optional)
- $key_file = "$MYHOME/maia.key";
  
  # $daemon_chroot_dir = $MYHOME;   # chroot directory or undef
  
  # $db_home   = "$MYHOME/db";
- # $helpers_home = "$MYHOME/var";  # prefer $MYHOME clean and owned by root?
- # $pid_file  = "$MYHOME/var/amavisd.pid";
- # $lock_file = "$MYHOME/var/amavisd.lock";
  #NOTE: create directories $MYHOME/tmp, $MYHOME/var, $MYHOME/db manually
  
  @local_domains_maps = ( [".$mydomain"] );
--- 3,27 ----
  use strict;
  
  $max_servers = 2;             # number of pre-forked children (2..15 is common)
+ $daemon_user  = '@@MAIA_USER@@';     # (no default;  customary: vscan or amavis)
+ $daemon_group = '@@MAIA_GROUP@@';     # (no default;  customary: vscan or amavis)
  
  $mydomain = 'yourdomain.tld'; # a convenient default for other settings
  
+ $MYHOME   = '@@LOCALSTATEDIR@@/lib/maia';   # a convenient default for other settings
  $TEMPBASE = "$MYHOME/tmp";    # working directory, needs to be created manually
  $ENV{TMPDIR} = $TEMPBASE;     # environment variable TMPDIR
+ $QUARANTINEDIR = '@@LOCALSTATEDIR@@/spool/maia-quarantine';
  
  # Blowfish encryption key file (optional)
+ $key_file = "@@SYSCONFDIR@@/maia/blowfish.key";
  
  # $daemon_chroot_dir = $MYHOME;   # chroot directory or undef
  
  # $db_home   = "$MYHOME/db";
+ $helpers_home = "$MYHOME/helpers";  # prefer $MYHOME clean and owned by root?
+ $pid_file  = "@@LOCALSTATEDIR@@/run/maia/amavisd.pid";
+ $lock_file = "@@LOCALSTATEDIR@@/lock/maia/amavisd.lock";
  #NOTE: create directories $MYHOME/tmp, $MYHOME/var, $MYHOME/db manually
  
  @local_domains_maps = ( [".$mydomain"] );

######################################################################

Please let me know if I can be of further asstiance.

Dale Sedivec

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <report-emacs-bug>

Recent messages:
Loading cl-seq...done
Loading /home/darkness/.elisp/packages/org/loaddefs.el (source)...done
Loading easy-mmode...done
Loading edmacro...done
Loading rng-auto.el (source)...done
Loading mwheel...done
Loading jka-compr...done
For information about the GNU Project and its goals, type C-h C-p.
Loading server...done
Loading emacsbug...done

Re: tramp and diff-mode results in Emacs crash

[Richard Stallman]

    - With Emacs and TRAMP both from Emacs' CVS, TRAMP had a problem that
      prevented me from attempting to reproduce the crash.

That problem is the bug we need to work on.  Have you sent a full report
for that bug?  If not, please do.

Once that is fixed, we will see if the other bug still exists.

Re: tramp and diff-mode results in Emacs crash

[Dale Sedivec]

On Sun, Feb 25, 2007 at 02:30:37PM -0500, Richard Stallman wrote:
>     - With Emacs and TRAMP both from Emacs' CVS, TRAMP had a problem that
>       prevented me from attempting to reproduce the crash.
> 
> That problem is the bug we need to work on.  Have you sent a full report
> for that bug?  If not, please do.
> 
> Once that is fixed, we will see if the other bug still exists.

	OK, I tried Emacs CVS checked out today, February 25th, at
16:25:45 EST, and TRAMP is working again.  I can now reproduce my bug
using the same procedure described previously:

- ~/software/emacs22/bin/emacs -q
- C-x C-f /10.0.1.169:foo.rej RET
- C-c C-u

	I see only "Back to top level."  The diff is unmodified by the
command.  Menus stop working, C-x C-b says "Back to top level." or
nothing, C-x b alternates between "S" and "Back to top level." in the
minibuffer without ever letting me change buffers, etc.

	So this bug exists in Emacs from CVS using the included TRAMP
2.0.55.

Dale

Re: tramp and diff-mode results in Emacs crash

[Michael Albinus]

Dale Sedivec <dale-dated-1172873680.43092c@codefu.org> writes:

> 	OK, I tried Emacs CVS checked out today, February 25th, at
> 16:25:45 EST, and TRAMP is working again.  I can now reproduce my bug
> using the same procedure described previously:
>
> - ~/software/emacs22/bin/emacs -q
> - C-x C-f /10.0.1.169:foo.rej RET
> - C-c C-u
>
> 	I see only "Back to top level."  The diff is unmodified by the
> command.  Menus stop working, C-x C-b says "Back to top level." or
> nothing, C-x b alternates between "S" and "Back to top level." in the
> minibuffer without ever letting me change buffers, etc.
>
> 	So this bug exists in Emacs from CVS using the included TRAMP
> 2.0.55.

What I can say is that I can reproduce the problem with a fresh GNU
Emacs 22.0.94 and builtin Tramp 2.0.55 (thanks for the example foo.rej).

With Tramp 2.1.9-pre from its CVS, same Emacs, this problem doesn't happen.

Hard to debug, because everything freezes. I suspect some concurrent
process filters fighting each other. I'll come back later (but this
might last one or two days).

> Dale

Best regards, Michael.

Re: tramp and diff-mode results in Emacs crash

[Chong Yidong]

Dale Sedivec <dale-dated-1172873680.43092c@codefu.org> writes:

> - ~/software/emacs22/bin/emacs -q
> - C-x C-f /10.0.1.169:foo.rej RET
> - C-c C-u
>
> 	I see only "Back to top level."  The diff is unmodified by the
> command.  Menus stop working, C-x C-b says "Back to top level." or
> nothing, C-x b alternates between "S" and "Back to top level." in the
> minibuffer without ever letting me change buffers, etc.

I checked in a fix for this.

(It's not a great fix, but it's the safest one I could think of.  The
problem arises when combine-after-change-calls is on.  The Tramp
filename handlers can be called (by lock_file) just before Emacs is
about to combine after-change calls, but those filename handlers can
themselves produce after-change calls because they scribble in temp
buffers.  It is possible to get Emacs into a confused state in this
way.  I simply made the Tramp handlers bind inhibit-modification-hooks
to avoid this problem.  We may want to revisit the interaction of file
modification hooks with combine-after-change-calls after the release.)

Re: tramp and diff-mode results in Emacs crash

[Stefan Monnier]

>> - ~/software/emacs22/bin/emacs -q
>> - C-x C-f /10.0.1.169:foo.rej RET
>> - C-c C-u
>> 
>> I see only "Back to top level."  The diff is unmodified by the
>> command.  Menus stop working, C-x C-b says "Back to top level." or
>> nothing, C-x b alternates between "S" and "Back to top level." in the
>> minibuffer without ever letting me change buffers, etc.

> I checked in a fix for this.

> (It's not a great fix, but it's the safest one I could think of.  The
> problem arises when combine-after-change-calls is on.  The Tramp
> filename handlers can be called (by lock_file) just before Emacs is
> about to combine after-change calls, but those filename handlers can
> themselves produce after-change calls because they scribble in temp
> buffers.  It is possible to get Emacs into a confused state in this
> way.  I simply made the Tramp handlers bind inhibit-modification-hooks
> to avoid this problem.  We may want to revisit the interaction of file
> modification hooks with combine-after-change-calls after the release.)

Maybe the workaround is OK, but I still don't understand what is the bug.
When using combine-after-change-calls, if changes are made in different
buffers, then the after-change-functions are run each time modifications are
done on a different buffer.

Oh, wait, you're saying that the problem is that when
combine-after-change-execute is run it begins by calling lock_file, which
causes more changes?  Hmm... I still don't see why that would be a problem.
Can you show some backtraces?


        Stefan

Re: tramp and diff-mode results in Emacs crash

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Oh, wait, you're saying that the problem is that when
> combine-after-change-execute is run it begins by calling lock_file, which
> causes more changes?  Hmm... I still don't see why that would be a problem.
> Can you show some backtraces?

I couldn't get Emacs to crash, but here is a backtrace from a
breakpoint just before Emacs gets confused.

Basically, insert_from_string calls prepare_to_modify_buffer before
signal_after_change (the latter is supposed to signal the changes due
to the insertion).  But prepare_to_modify_buffer calls lock_file,
which calls the Tramp file handlers, which does its own insertion in a
temp buffer, which runs signal_after_change, which first runs
signal_after_change on the original buffer---all this happens *before*
signal_before_change on the original buffer gets to run!

This analysis indicates that the more general solution is to bind
inhibit_modification_hooks around the call to lock_file in
prepare_to_modify_buffer, but that seems to me too risky a change at
this stage in the release.

#0  signal_after_change (charpos=1, lendel=0, lenins=12) at insdel.c:2257
#1  0x0811a625 in insert_from_string (string=141595915, pos=0, pos_byte=0, 
    length=12, length_byte=12, inherit=0) at insdel.c:1069
#2  0x08153f7d in general_insert_function (insert_func=0x811aab0 <insert>, 
    insert_from_string_func=0x811a5a0 <insert_from_string>, inherit=0, 
    nargs=1, args=0xbf89bd20) at editfns.c:2176
#3  0x081540b4 in Finsert (nargs=1, args=0xbf89bd20) at editfns.c:2220
#4  0x081874af in Fbyte_code (bytestr=141230795, vector=141367012, maxdepth=40)
    at bytecode.c:1258
#5  0x0815c2c7 in funcall_lambda (fun=141379860, nargs=2, 
    arg_vector=0xbf89be54) at eval.c:3184
#6  0x0815c711 in Ffuncall (nargs=3, args=0xbf89be50) at eval.c:3054
#7  0x0818793d in Fbyte_code (bytestr=141403235, vector=141259140, maxdepth=56)
    at bytecode.c:679
#8  0x0815c2c7 in funcall_lambda (fun=141142596, nargs=5, 
    arg_vector=0xbf89bf84) at eval.c:3184
#9  0x0815c711 in Ffuncall (nargs=6, args=0xbf89bf80) at eval.c:3054
#10 0x0818793d in Fbyte_code (bytestr=140040251, vector=139888212, maxdepth=80)
    at bytecode.c:679
#11 0x0815c2c7 in funcall_lambda (fun=140530676, nargs=2, 
    arg_vector=0xbf89c0c4) at eval.c:3184
#12 0x0815c711 in Ffuncall (nargs=3, args=0xbf89c0c0) at eval.c:3054
#13 0x0815e029 in Fapply (nargs=2, args=0xbf89c194) at eval.c:2485
#14 0x0815ca5a in Ffuncall (nargs=3, args=0xbf89c190) at eval.c:2978
#15 0x0818793d in Fbyte_code (bytestr=139878275, vector=141549748, maxdepth=32)
    at bytecode.c:679
#16 0x0815c2c7 in funcall_lambda (fun=141253452, nargs=3, 
    arg_vector=0xbf89c2b4) at eval.c:3184
#17 0x0815c711 in Ffuncall (nargs=4, args=0xbf89c2b0) at eval.c:3054
#18 0x0815e029 in Fapply (nargs=3, args=0xbf89c384) at eval.c:2485
#19 0x0815ca5a in Ffuncall (nargs=4, args=0xbf89c380) at eval.c:2978
#20 0x0818793d in Fbyte_code (bytestr=139878451, vector=141181604, maxdepth=32)
    at bytecode.c:679
#21 0x0815c2c7 in funcall_lambda (fun=139934292, nargs=3, 
    arg_vector=0xbf89c4a4) at eval.c:3184
#22 0x0815c711 in Ffuncall (nargs=4, args=0xbf89c4a0) at eval.c:3054
#23 0x0815cae9 in call3 (fn=138328817, arg1=137589513, arg2=141839179, 
    arg3=137472201) at eval.c:2827
#24 0x0812376c in Fexpand_file_name (name=141839179, 
    default_directory=137472201) at fileio.c:1721
#25 0x08117adc in lock_file (fn=141839179) at filelock.c:605
#26 0x0811869a in prepare_to_modify_buffer (start=1, end=1, preserve_ptr=0x0)
    at insdel.c:2085
#27 0x0811a2ec in insert_from_string_1 (string=<value optimized out>, pos=0, 
    pos_byte=0, nchars=3, nbytes=3, inherit=0, before_markers=0)
    at insdel.c:1121
#28 0x0811a607 in insert_from_string (string=139867003, pos=0, pos_byte=0, 
    length=3, length_byte=3, inherit=0) at insdel.c:1067
#29 0x08153f7d in general_insert_function (insert_func=0x811aab0 <insert>, 
    insert_from_string_func=0x811a5a0 <insert_from_string>, inherit=0, 
    nargs=1, args=0xbf89c660) at editfns.c:2176
#30 0x081540b4 in Finsert (nargs=1, args=0xbf89c660) at editfns.c:2220
#31 0x0815bf1b in Feval (form=138970861) at eval.c:2301
#32 0x0815c11f in Fprogn (args=137472201) at eval.c:447
#33 0x0815e755 in Flet (args=138970869) at eval.c:1064
#34 0x0815bf3d in Feval (form=138970901) at eval.c:2275
#35 0x0815c11f in Fprogn (args=137472201) at eval.c:447
#36 0x0815c3b4 in funcall_lambda (fun=138970784, nargs=0, 
    arg_vector=0xbf89c894) at eval.c:3177
#37 0x0815c711 in Ffuncall (nargs=1, args=0xbf89c890) at eval.c:3054
#38 0x0815e189 in apply1 (fn=138970789, arg=137472201) at eval.c:2738
#39 0x08159869 in Fcall_interactively (function=138970789, 
    record_flag=137472201, keys=137512716) at callint.c:406
#40 0x080f9313 in Fcommand_execute (cmd=138970789, record_flag=137472201, 
    keys=137472201, special=137472201) at keyboard.c:10014
#41 0x08104d39 in command_loop_1 () at keyboard.c:1873
#42 0x0815b2d2 in internal_condition_case (bfun=0x81049b0 <command_loop_1>, 
    handlers=137516857, hfun=0x80ff400 <cmd_error>) at eval.c:1481
#43 0x080fe7b3 in command_loop_2 () at keyboard.c:1329
---Type <return> to continue, or q <return> to quit---
#44 0x0815b38a in internal_catch (tag=137510841, 
    func=0x80fe790 <command_loop_2>, arg=137472201) at eval.c:1222
#45 0x080ff23c in command_loop () at keyboard.c:1308
#46 0x080ff5fa in recursive_edit_1 () at keyboard.c:1006
#47 0x080ff6e6 in Frecursive_edit () at keyboard.c:1067
#48 0x080f5405 in main (argc=3, argv=0xbf89d134) at emacs.c:1761

Lisp Backtrace:
"format-spec" (0x870950b)
"tramp-make-tramp-file-name" (0x831a8c9)
"tramp-handle-expand-file-name" (0x8744b4b)
"apply" (0x86fd461)
"tramp-sh-file-name-handler" (0x8337309)
"apply" (0x86fd9e1)
"tramp-file-name-handler" (0x8337309)
"insert" (0x856337b)
"let" (0x84886f5)
0x84886a5 Lisp type 5
"call-interactively" (0x84886a5)

Re: tramp and diff-mode results in Emacs crash

[Stefan Monnier]

>> Oh, wait, you're saying that the problem is that when
>> combine-after-change-execute is run it begins by calling lock_file, which
>> causes more changes?  Hmm... I still don't see why that would be a problem.
>> Can you show some backtraces?

> I couldn't get Emacs to crash, but here is a backtrace from a
> breakpoint just before Emacs gets confused.

> Basically, insert_from_string calls prepare_to_modify_buffer before
> signal_after_change (the latter is supposed to signal the changes due
> to the insertion).  But prepare_to_modify_buffer calls lock_file,
> which calls the Tramp file handlers, which does its own insertion in a
> temp buffer, which runs signal_after_change, which first runs
> signal_after_change on the original buffer---all this happens *before*
> signal_before_change on the original buffer gets to run!

Why is the above sequence a problem?

> This analysis indicates that the more general solution is to bind
> inhibit_modification_hooks around the call to lock_file in
> prepare_to_modify_buffer, but that seems to me too risky a change at
> this stage in the release.

It still feels like it'd hide the problem rather than fix it.
But maybe it's just because I still don't know what the problem is.


        Stefan

Re: tramp and diff-mode results in Emacs crash

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Basically, insert_from_string calls prepare_to_modify_buffer before
>> signal_after_change (the latter is supposed to signal the changes due
>> to the insertion).  But prepare_to_modify_buffer calls lock_file,
>> which calls the Tramp file handlers, which does its own insertion in a
>> temp buffer, which runs signal_after_change, which first runs
>> signal_after_change on the original buffer---all this happens *before*
>> signal_before_change on the original buffer gets to run!
>
> Why is the above sequence a problem?
>
> It still feels like it'd hide the problem rather than fix it.
> But maybe it's just because I still don't know what the problem is.

You're right, I wasn't thinking very clearly about the problem.  But I
now know what it is.

Basically, after the file handler performs its changes, it's time for
the original insertion to combine its after-change calls.  But it has
to perform combine-after-change execute for the temp file changes made
by the file handler.  But combine_after_change_buffer will no longer
be valid since the temp file was destroyed, and the call to set-buffer
in combine-after-change-execute fails.

So I reverted my previous change, and changed combine-after-change-execute
to return nil when combine_after_change_buffer is not a valid buffer.
This fixes the bug too, and I think it shouldn't be much more
dangerous than the previous workaround.

Re: tramp and diff-mode results in Emacs crash

[Stefan Monnier]

> So I reverted my previous change, and changed combine-after-change-execute
> to return nil when combine_after_change_buffer is not a valid buffer.
> This fixes the bug too, and I think it shouldn't be much more
> dangerous than the previous workaround.

That looks good, thank you.  The only problem that I can see with it, is
that we end up not running the hooks at all.  But there's no much we can do.
At best, we could try to run them before killing the buffer (e.g. from
Fkill_buffer) but I'm not sure it's worth the trouble.


        Stefan