GNU bug report logs - #13743
24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere

Previous Next

Full log

Message #92 received at 13743 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 13743 <at> debbugs.gnu.org
Subject: Re: bug#13743: 24.2.93; Segmentation fault when trying to [s]teal
	a file opened elsewhere
Date: Tue, 26 Feb 2013 07:59:36 +0400

On 26.02.2013 7:51, Eli Zaretskii wrote:
>> Date: Tue, 26 Feb 2013 03:23:11 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: monnier <at> iro.umontreal.ca, 13743 <at> 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 <at> yandex.ru>
>>>> CC: monnier <at> iro.umontreal.ca, 13743 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.