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

[Eli Zaretskii]

> 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.