Re: allocate_string_data memory corruption

[Chong Yidong]

"Richard M. Stallman" <address@hidden> writes:

>     I don't see any better solution.  It is non-trivial to fix the
>     behavior of handle_one_xevent with synched input.  I, for one, don't
>     see any clean way to fix note_mouse_highlight and
>     x_handle_dnd_message.
>
> Could you tell us about these problems?

Sure.  We already discussed the note_mouse_highlight problem somewhat.
Basically, it can lead to calling realize_face for a mouse face, which
can call allocate_vectorlike and make_uninit_multibyte_string.  I
don't know how to avoid this, since the mouse face is constructed on
the fly by merging overlay and text property mouse faces.

As for x_handle_dnd_message, this function has to allocate a vector,
recording the filename "dragged and dropped" into Emacs, that is put
into the arg member of a struct input_event for later processing.  We
can't change the arg member from a Lisp_Object to a pointer (and use a
malloc'ed block instead of a vector) because the arg member is used by
other event handlers to pass stuff (e.g., the toolbar handlers).  One
solution is to add an additional pointer member to struct input_event,
or make a global variable to store drag and drop events.  But I'd
rather not put any more effort into tweaking handle_one_xevent to
avoid allocating Lisp structures.  After the release, we can fix
DSYNC_INPUT and make it the default -- DSYNC_INPUT just seems like a
better design.

> Would you please install your patch?

Done.

Can we move forward with the release now?  I believe this was the main
bug blocking the process.