Emacs WIN32 crashes on reinitialzing of lisp process using slime

Emacs WIN32 crashes on reinitialzing of lisp process using slime

[cb]

When calling M-X slime and answering the question "create an additional
inferior-lisp (y/n)" with n Emacs crashes on WIN32.

The call eventually results in (kill-buffer " *cl-connection*"), so this can be
called to test the whole thing.

Emacs has been built using MINGW and MSYS. The described crash appears on all
versions since 22.0.91 and with all slime variants.

I hope this report contains everything you need, to reproduce the crash.

Thanks,

Carsten

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Eli Zaretskii]

> From: cb <carstenblaauw@web.de>
> Date: Wed, 11 Apr 2007 19:01:26 +0000 (UTC)
> 
> When calling M-X slime and answering the question "create an additional
> inferior-lisp (y/n)" with n Emacs crashes on WIN32.

What is slime? it's not part of the Emacs distribution.

> The call eventually results in (kill-buffer " *cl-connection*"), so this can be
> called to test the whole thing.

You mean, the call to kill-buffer crashes?  I hope you don't mean that
kill-buffer crashes in general, for any buffer, because that's
certainly not what I see.

> Emacs has been built using MINGW and MSYS.

Please state the versions of the main tools used.

> I hope this report contains everything you need, to reproduce the crash.

Please also use report-emacs-bug, which reports additional information
that might be of importance.

Thanks.

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[cb]

Eli Zaretskii <eliz <at> gnu.org> writes:

> What is slime? it's not part of the Emacs distribution.

No, but I could not reproduce the crash without it. Slime can be found on
"http://common-lisp.net/project/slime"

> You mean, the call to kill-buffer crashes?  I hope you don't mean that
> kill-buffer crashes in general, for any buffer, because that's
> certainly not what I see.

No, just when you kill that particular buffer and slime has been started. I
compiled the same source under FreeBSD and there everything works. Maybe it is a
slime problem, but I think Emacs should never crash, whatever you throw at it. I
tried it with clisp and sbcl as a backend and in both cases Emacs crashed after
closing the connection to the swank backend.

> Please state the versions of the main tools used.

If I recall correctly MINGW was version 5.6 and MSYS version 1.1, but the same
behavior can be seen using the Emacs W32 version from
"http://www.ourcomments.org/Emacs/EmacsW32.html", but I don't know what build
tool configuration was used building that one.

> Please also use report-emacs-bug, which reports additional information
> that might be of importance.

Ok, I'll try that, too. I hope our firewall lets me do that.

> Thanks.

Thank you for your hard and good work on Emacs, have a nice day


Carsten

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Eli Zaretskii]

> From: cb <carstenblaauw@web.de>
> Date: Thu, 12 Apr 2007 05:31:32 +0000 (UTC)
> 
> No, but I could not reproduce the crash without it. Slime can be found on
> "http://common-lisp.net/project/slime"

Can't you reduce slime to some minimally self-contained recipe, so
that one wouldn't have to install a package just to debug a crash?

> I think Emacs should never crash, whatever you throw at it.

That is an impossible goal, but we certainly try to get as close as
practically possible.

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Jason Rumney]

Eli Zaretskii wrote:
>> From: cb <carstenblaauw@web.de>
>> Date: Thu, 12 Apr 2007 05:31:32 +0000 (UTC)
>>
>> No, but I could not reproduce the crash without it. Slime can be found on
>> "http://common-lisp.net/project/slime"
>>     
>
> Can't you reduce slime to some minimally self-contained recipe, so
> that one wouldn't have to install a package just to debug a crash?
>   

I have narrowed down the crash to a call to free_buffer_text(b) on line 
4967 of buffer.c. It seems to be inlined, so in the stack trace it 
claims to be in Fkill_buffer, but the line number appears to be correct, 
as there is a call to r_alloc_free on that line, which is where the 
abort is coming from, apparently because b->text->beg (which we are 
freeing) is NULL.

Changing r_alloc_free to handle freeing NULL silently will get rid of 
the crash, but may disguise other bugs.

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Jason Rumney]

Jason Rumney wrote:
> I have narrowed down the crash to a call to free_buffer_text(b) on 
> line 4967 of buffer.c. It seems to be inlined, so in the stack trace 
> it claims to be in Fkill_buffer, but the line number appears to be 
> correct, as there is a call to r_alloc_free on that line, which is 
> where the abort is coming from, apparently because b->text->beg (which 
> we are freeing) is NULL.
>
> Changing r_alloc_free to handle freeing NULL silently will get rid of 
> the crash, but may disguise other bugs.

Further investigation shows that the kill-buffer is called recursively 
on the same buffer in slime-net-close, due to the hooks calling 
slime-net-sentinel which in turn calls slime-net-close again.

So a simple test case can probably be found by trying to reproduce that 
recursion.

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Eli Zaretskii]

> Date: Thu, 12 Apr 2007 23:40:15 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, cb <carstenblaauw@web.de>,
> 	emacs-devel@gnu.org
> 
> Further investigation shows that the kill-buffer is called recursively 
> on the same buffer in slime-net-close, due to the hooks calling 
> slime-net-sentinel which in turn calls slime-net-close again.

That means the problem is not really Windows-specific.

How come recursive kill-buffer causes r_alloc_free to be called with a
NULL pointer?

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Jason Rumney]

Eli Zaretskii wrote:
>> Date: Thu, 12 Apr 2007 23:40:15 +0100
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, cb <carstenblaauw@web.de>,
>> 	emacs-devel@gnu.org
>>
>> Further investigation shows that the kill-buffer is called recursively 
>> on the same buffer in slime-net-close, due to the hooks calling 
>> slime-net-sentinel which in turn calls slime-net-close again.
>>     
>
> That means the problem is not really Windows-specific.
>   
Probably not. There doesn't seem to be any windows specific code 
involved anywhere in the stack.

> How come recursive kill-buffer causes r_alloc_free to be called with a
> NULL pointer?
>   

I don't know. I couldn't reproduce it by setting a kill-buffer-hook that 
calls kill-buffer, so it must be specific to the way it is done by slime 
(using a process-sentinel rather than kill-buffer-hook).

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[martin rudalics]

 > I don't know. I couldn't reproduce it by setting a kill-buffer-hook that
 > calls kill-buffer, so it must be specific to the way it is done by slime
 > (using a process-sentinel rather than kill-buffer-hook).

kill-buffer has a window of opportunity before it sets buffer-name to
nil.  Could you try reproducing the slime crash with the patch I sent to
emacs-pretest?

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Kim F. Storm]

martin rudalics <rudalics@gmx.at> writes:

>> I don't know. I couldn't reproduce it by setting a kill-buffer-hook that
>> calls kill-buffer, so it must be specific to the way it is done by slime
>> (using a process-sentinel rather than kill-buffer-hook).
>
> kill-buffer has a window of opportunity before it sets buffer-name to
> nil.  Could you try reproducing the slime crash with the patch I sent to
> emacs-pretest?

Could you also try if the following (simpler) patch gives good results.


*** buffer.c	29 Mar 2007 22:06:47 +0200	1.525
--- buffer.c	13 Apr 2007 14:17:29 +0200	
***************
*** 1458,1464 ****
--- 1458,1470 ----
    unlock_buffer (b);
  #endif /* CLASH_DETECTION */
  
+   GCPRO1 (buf);
    kill_buffer_processes (buf);
+   UNGCPRO;
+ 
+   if (NILP (b->name))
+     return Qnil;
+ 
    clear_charpos_cache (b);
  
    tem = Vinhibit_quit;


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Jason Rumney]

Kim F. Storm wrote:
> Could you also try if the following (simpler) patch gives good results.
>   

Both patches seem to fix the problem for me.

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Kim F. Storm wrote:
>> Could you also try if the following (simpler) patch gives good results.
>>   
>
> Both patches seem to fix the problem for me.

Thank you all for reporting, debugging and testing.

I have installed my (simpler) patch.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Eli Zaretskii]

> Cc: Jason Rumney <jasonr@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,
> 	  carstenblaauw@web.de,  emacs-devel@gnu.org
> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 13 Apr 2007 14:20:19 +0200
> 
> +   if (NILP (b->name))
> +     return Qnil;
> + 

Please put here a comment explaining when is b->name nil, and perhaps
even citing slime and this discussion.  Otherwise in a few years,
someone might become tempted to remove it.

Thanks.

Re: Emacs WIN32 crashes on reinitialzing of lisp process using slime

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Jason Rumney <jasonr@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,
>> 	  carstenblaauw@web.de,  emacs-devel@gnu.org
>> From: storm@cua.dk (Kim F. Storm)
>> Date: Fri, 13 Apr 2007 14:20:19 +0200
>> 
>> +   if (NILP (b->name))
>> +     return Qnil;
>> + 
>
> Please put here a comment explaining when is b->name nil, and perhaps
> even citing slime and this discussion.  Otherwise in a few years,
> someone might become tempted to remove it.

I added a suitable (generic) comment when I installed the patch.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk