bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere

[Dmitry Gutov]

On 26.02.2013 22:42, Eli Zaretskii wrote:
> > Date: Tue, 26 Feb 2013 07:59:36 +0400
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
> >
> > On 26.02.2013 7:51, Eli Zaretskii wrote:
> > > > Date: Tue, 26 Feb 2013 03:23:11 +0400
> > > > From: Dmitry Gutov <dgutov@yandex.ru>
> > > > CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
> > > >
> > > > On 25.02.2013 23:31, Eli Zaretskii wrote:
> > > > > > Date: Mon, 25 Feb 2013 23:08:04 +0400
> > > > > > From: Dmitry Gutov <dgutov@yandex.ru>
> > > > > > CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
> > > > > >
> > > > > > On 25.02.2013 20:27, Eli Zaretskii wrote:
> > > > > > > Btw, what mmm-mode does is quite nasty, because it causes stale lock
> > > > > > > files to be left behind, if you press 'p' when Emacs says that the
> > > > > > > file is locked.  This is because mmm-mode makes the buffer unmodified
> > > > > > > again after doing whatever it is that causes these prompts, and if you
> > > > > > > then kill Emacs without ever editing the file, the function that
> > > > > > > unlocks the file is not called (because the buffer is not modified).
> > > > > >
> > > > > > AFAICT, it only did that to make sure the subsequent `kill-buffer'
> > > > > > doesn't query the user. It doesn't seem to do that either way, so I
> > > > > > removed the `set-buffer-modified-p' call.
> > > > >
> > > > > And after removing that call, do you end up with a "modified" buffer
> > > > > after visiting a file?
> > > >
> > > > Nope.
> > >
> > > Then the root cause is still there: the file is locked by an operation
> > > that leaves the buffer unmodified.
> >
> > Any ideas what that might be? mmm-mode initialization code is rather
> > complex.
>
> I suggest to run Emacs under GDB, put a breakpoint in lock_file and
> unlock_file, and when they break, see who calls them in C and in Lisp.

Thanks, this little investigation has resulted in Bug#13836, please take 
a look when you have the time.

Meanwhile, binding `buffer-file-truename' to nil around the whole 
indirect-buffer business seems to work around this well enough.