GNOME Bugzilla – Bug 795596
rtspconnection: GError set over the top of a previous GError or uninitialized memory.
Last modified: 2018-11-03 12:06:27 UTC
file: gstrtspconnection.c functions: read_bytes(), write_bytes(), fill_bytes() The functions do not have handling for the situation that sub-functions return both a positive number of bytes and an error at the same time. The problem is discovered in the next lap of the while-loop when the error has not been cleared from the previous lap, and this error print is issued: "GError set over the top of a previous GError or uninitialized memory."
Created attachment 371454 [details] [review] Patch to address the problem The proposed patch goes to error not only when returned number of bytes is non-negative but also when err is set. This change required some rework of the error handling. The function write_bytes() is aligned to the read_byte() function for handling the case where returned bytes is zero.
Created attachment 371457 [details] [review] Patch to address the problem Same comment as for obsoleted attachment 371454 [details] [review]. The only difference is an updated print format specifier.
Created attachment 371668 [details] Obsolete patch 371457 Problem with rtsph detected. The current patch is obsoleted. A new patch will be provided when verified.
Created attachment 372114 [details] [review] gstrtspconnection.c: Error handling in write_bytes() and read_bytes() The proposed patch goes to error handling not only based on the return value from functions but also when err is set. The change required some rework of the error handling.
Has anyone had a chance to look at this yet?
Right, so I see that the warning/critical needs fixing, and I understand how that happens. What is not entirely clear to me yet if this is the right change. What error is being returned in this case where it returns a non-negative number as well? Is this intentional and expected or perhaps a bug in the underlying code in GLib?
> What error is being returned in this case where it returns a non-negative number as well? The returned error is depending on the G_IO_ERROR with GST_RTSP_ESYS as default, as before. > Is this intentional and expected or perhaps a bug in the underlying code in GLib? Well, the GLib documentation states "the number of bytes ..., or -1 on error" for both the underlying GLib functions (g_pollable_output_stream_write_nonblocking and g_pollable_input_stream_read_nonblocking), so at least one could say that the GLib implementation does not match the GLib documentation.
(In reply to Nils Öhnell from comment #7) > > What error is being returned in this case where it returns a non-negative number as well? > The returned error is depending on the G_IO_ERROR with GST_RTSP_ESYS as > default, as before. I think the question was what the actual GIO error is that happens here > > Is this intentional and expected or perhaps a bug in the underlying code in GLib? > Well, the GLib documentation states "the number of bytes ..., or -1 on > error" for both the underlying GLib functions > (g_pollable_output_stream_write_nonblocking and > g_pollable_input_stream_read_nonblocking), so at least one could say that > the GLib implementation does not match the GLib documentation. Can you file a bug about that again GLib? This is definitely not correct, both for the given documentation and the behaviour that code relies on everywhere with regards to these functions. Does this happen with direct TCP connections, or via TLS, or ...?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/445.