<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - File descriptor leak in gdk_wayland_selection_request_target()" href="https://bugzilla.gnome.org/show_bug.cgi?id=751414#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - File descriptor leak in gdk_wayland_selection_request_target()" href="https://bugzilla.gnome.org/show_bug.cgi?id=751414">bug 751414</a> from <a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> Carlos Garnacho</a> <pre>(In reply to Michael Catanzaro from <a href="show_bug.cgi?id=751414#c14">comment #14</a>) > > 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 <a href="show_bug.cgi?id=751414#c15">comment #15</a>) > <a href="attachment.cgi?id=306033&action=diff" name="attach_306033" title="wayland: Do not close the descriptor on async_write_data_free()">Attachment #306033</a> <a href="attachment.cgi?id=306033&action=edit" title="wayland: Do not close the descriptor on async_write_data_free()">[details]</a> looks correct to me. > > <a href="attachment.cgi?id=306034&action=diff" name="attach_306034" title="wayland: Ensure we cancel previous selection writes before starting one">Attachment #306034</a> <a href="attachment.cgi?id=306034&action=edit" title="wayland: Ensure we cancel previous selection writes before starting one">[details]</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>