[Wayland-bugs] [Bug 751414] File descriptor leak in gdk_wayland_selection_request_target()

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=751414

--- Comment #16 from Carlos Garnacho <carlosg at gnome.org> ---
(In reply to Michael Catanzaro from comment #14)
> 
> The read() currently never completes (without your patches applied; I will
> test them now), presumably due to the missing cancel. (Note: I have to
> receive data in each possible MIME type even if it won't be used in order to
> hook up to Chrome's existing cross-platform drag-and-drop abstraction.)
> 
> To work properly with GTK+, I will need to modify my code to do the
> following:
> 
> * foreach offered MIME type Chrome could ever possibly accept
>   * call wl_data_offer_receive()
>   * Pass the received fd to the other process over internal IPC
>   * In the other process, read() the data from each fd
>   * Close the fd
>   * Tell the original process it's safe to use wl_data_offer_receive() again
> 
> Correct?

Yeah, that'd be one way to work around the "1 request on the fly" limitation,
is it too much of a change to?:

* forward all mimetypes to the other process over internal IPC
* In the other process, pick one and tell about it to the original process
* call wl_data_offer_receive on that one, pass the fd.
* In the other process, read() and close

TBH I wonder how often does the web process end up using more than one
mimetype, probably never?

> 
> Do you consider this a deficiency in GTK+ worth changing eventually? (But if
> so, we'd need a plan to prevent the drag destination from causing clients to
> use arbitrarily many fds.) Or would it be better to change the Wayland
> protocol documentation to indicate that wl_data_offer_receive() should not
> be used multiple times in a row without first closing the
> previously-received pipe?

Selections and DnD APIs are indeed calling for a redesign, probably lowering
everything to GDK and making it all GAsyncResult driven (sounds like a 4.x
target though). 

However, on X11 the limitation is at the guts of the selections mechanism, so
it's unclear to me whether we can safely support this across backends.

(In reply to Michael Catanzaro from comment #15)
> Attachment #306033 [details] looks correct to me.
> 
> Attachment #306034 [details] also looks correct, and causes my read() in
> Chrome to complete (although only one read() actually receives data, of
> course).
> 
> However, the fd leak still occurs.

Ok, saw what's going on :). because the emission of the GdkEventSelection is
handled on the main loop, requesting data through fds like in your weston hack
makes a bunch of calls to gdk_wayland_selection_request_target(), but no final
call to gdk_wayland_selection_check_write(), so we just replace the previous fd
and leak it, a third patch coming.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150624/62de5e9e/attachment.html>