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

[Dmitry Gutov <dgutov@yandex.ru>]

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.