After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754432 - curlsink: FTP active connection not handled properly in error case (aborted transfer)
curlsink: FTP active connection not handled properly in error case (aborted t...
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.6.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-09-02 07:50 UTC by Patricia Muscalu
Modified: 2016-04-14 17:42 UTC
See Also:
GNOME target: ---
GNOME version: ---

report an unknown error (1.16 KB, patch)
2015-09-08 13:12 UTC, Patricia Muscalu
none Details | Review
report an unknown error (1.31 KB, patch)
2015-09-14 09:21 UTC, Patricia Muscalu
none Details | Review
report an unknown error (1.26 KB, patch)
2015-09-15 13:56 UTC, Patricia Muscalu
committed Details | Review

Description Patricia Muscalu 2015-09-02 07:50:33 UTC
This problem has been discovered while testing FTP upload against FileZilla server ,that probably aborts an ongoing transfer in an inappropriate way, however this situation should be handled properly in curlsink.

Two problems exist:

1) In the case when the data session has not been established any attempt to its "removal" results in 
GStreamer-CRITICAL **: gst_poll_remove_fd: assertion 'fd->fd >= 0' failed

2) There is no error message generated when data transfer is aborted by FTP server
(FTP server response: 426 Connection closed; transfer aborted).
This depends on a bug existing in libcurl, that already has been reported here:
1) easy to solve but I'm awaiting a solution to 2) before sending a final fix to this problem
Comment 1 Patricia Muscalu 2015-09-08 13:12:36 UTC
Created attachment 310899 [details] [review]
report an unknown error
Comment 2 Patricia Muscalu 2015-09-08 13:14:21 UTC
Please, have a look at the attached patch. Thank you.
Comment 3 Patricia Muscalu 2015-09-14 09:21:20 UTC
Created attachment 311264 [details] [review]
report an unknown error
Comment 4 Patricia Muscalu 2015-09-14 09:21:59 UTC
Updated the patch with a comment.
Comment 5 Tim-Philipp Müller 2015-09-15 13:35:10 UTC
So is this a workaround for a bug in libcurl? If yes, we should put a

  /* FIXME: remove this again once we can depend on libcurl >= a.b.c,
   * see $bug_url */

above the code block.

Or is it an expected failure mode at this point and will be in future versions (with that libcurl change you linked)?
Comment 6 Patricia Muscalu 2015-09-15 13:56:44 UTC
Created attachment 311373 [details] [review]
report an unknown error
Comment 7 Patricia Muscalu 2015-09-15 13:57:39 UTC
Yes, it's a workaround for a bug in libcurl. I've put a FIXME. Thanks!
Comment 8 Tim-Philipp Müller 2016-04-04 17:01:14 UTC
Looks like this one fell through the cracks, sorry!

commit 0fbbbd042a115e2520f7c99d874617d88a711878
Author: Patricia Muscalu <>
Date:   Tue Sep 8 14:37:57 2015 +0200

    curlsink: catch an unknown error
    In this case the socket callback has not been called
    by libcurl and the curlsink has not been notified about any
    connection problems by libcurl.
    This indicates that it's a bug in libcurl so catch it as
    an unknown error.
Comment 9 Patricia Muscalu 2016-04-05 06:19:23 UTC
Thank you!