bug#17510: 24.3.91; Problem with `emacs --daemon' in cygw32 build

[Ken Brown]

On 5/24/2014 3:28 PM, Daniel Colascione wrote:
> On 05/24/2014 05:38 AM, Ken Brown wrote:
> > On 5/19/2014 3:25 PM, Ken Brown wrote:
> > > On 5/19/2014 12:46 PM, Eli Zaretskii wrote:
> > > > I guess it's OK for the branch, thanks.  But it strikes me that simply
> > > > replacing the car of dpyinfo->name_list_element by something like
> > > > "!!!DELETED DISPLAY!!!", or even just an empty string, would serve the
> > > > same purpose, and save us the nuisance of an additional list in
> > > > cygw32_display_name_list.  After all, all you need is to mark a
> > > > display deleted without actually deleting it, right?  IOW, the main
> > > > problem is in x_delete_display, and all the rest is just the overhead
> > > > you needed to fix that, correct?
> > >
> > > I think that's correct, and I agree that there should be a much simpler
> > > fix.  I'll have to look into the code and try to understand better
> > > exactly what happens when emacs is started as a daemon and then a client
> > > frame is opened and closed.
> >
> > My guess as to the cause of this bug was completely wrong.  What happens
> > in my recipe is that the pointer dpyinfo->w32_id_name is freed twice.
> > (This is done in x_delete_display each time the only existing client
> > frame is deleted.)  An attempt to create a client frame for the third
> > time then leads to a crash because of malloc corruption.
>
> Thanks for finding that. I wonder whether this double-free also has
> something to do with random crashes people have been seeing in 64-bit
> Cygwin cygw32 Emacs builds.

I doubt it, because this double-free occurs in both 64-bit and 32-bit 
Cygwin.  Also, I think it can only be triggered by running emacs as a 
daemon, and none of the people reporting crashes mentioned doing that.

Ken