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 733974 - gstbufferpool::default_alloc_buffer does not fail if buffer allocation fails
gstbufferpool::default_alloc_buffer does not fail if buffer allocation fails
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.4.0
Other Linux
: Normal normal
: 1.4.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-07-30 12:28 UTC by Mohammed Sameer
Modified: 2014-07-30 13:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed fix (902 bytes, patch)
2014-07-30 12:48 UTC, Mohammed Sameer
accepted-commit_now Details | Review

Description Mohammed Sameer 2014-07-30 12:28:15 UTC
Currently do_alloc_buffer() calls default_alloc_buffer() which calls gst_buffer_new_allocate()

If gst_buffer_new_allocate() fails to allocate a buffer and returns NULL then default_alloc_buffer() should check for that NULL buffer and return an error which is not the case currently.

I am not yet attached a patch since I am not sure what to do. A proposed fix could be:
diff --git a/gst/gstbufferpool.c b/gst/gstbufferpool.c
index 6509225..5cd5ddc 100644
--- a/gst/gstbufferpool.c
+++ b/gst/gstbufferpool.c
@@ -227,6 +227,9 @@ default_alloc_buffer (GstBufferPool * pool, GstBuffer ** buffer,
   *buffer =
       gst_buffer_new_allocate (priv->allocator, priv->size, &priv->params);
 
+  if (!*buffer)
+    return GST_FLOW_ERROR;
+
   return GST_FLOW_OK;
 }
 

However the documentation of GStreamer says that elements returning GST_FLOW_ERROR should post an error message wth more details and I am not sure how to do this since GstBufferPool is not really a GstElement.
Comment 1 Mohammed Sameer 2014-07-30 12:48:43 UTC
Created attachment 282048 [details] [review]
proposed fix
Comment 2 Nicolas Dufresne (ndufresne) 2014-07-30 12:52:30 UTC
Review of attachment 282048 [details] [review]:

That's true, if the allocator is not the default allocator, it may fail (unlike the system allocator). Thanks for your patch.
Comment 3 Nicolas Dufresne (ndufresne) 2014-07-30 13:04:32 UTC
commit 59749833bb702d59d7a6c0c6935f388dd602b2f2
Author: Mohammed Sameer <msameer@foolab.org>
Date:   Wed Jul 30 15:46:22 2014 +0300

    bufferpool: Add missing error checking to default_alloc_buffer()
    
    default_alloc_buffer() calls gst_buffer_new_allocate() but does not check for
    failed allocation.
    
    This patch makes default_alloc_buffer() return an error (GST_FLOW_ERROR) if
    buffer allocation fails.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=733974

Shall we backport this one ? Was there a failing use case for you ? For the context, this never happens with system allocator, as it will abort the application and other uses their own buffer pool, with the own allocate method.
Comment 4 Mohammed Sameer 2014-07-30 13:09:56 UTC
(In reply to comment #3)
> Shall we backport this one ? Was there a failing use case for you ? For the
> context, this never happens with system allocator, as it will abort the
> application and other uses their own buffer pool, with the own allocate method.

I am using a custom allocator which apparently failed for an unknown reason and I ended up hitting this path. I am not sure if anyone else will really hit this issue or not.

We already have a few allocators (dma buf and an egl one). If they can fail then I'd guess it'd be better t backport since 1.6 is definitely not in the near future.
Comment 5 Nicolas Dufresne (ndufresne) 2014-07-30 13:18:09 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Shall we backport this one ? Was there a failing use case for you ? For the
> > context, this never happens with system allocator, as it will abort the
> > application and other uses their own buffer pool, with the own allocate method.
> 
> I am using a custom allocator which apparently failed for an unknown reason and
> I ended up hitting this path. I am not sure if anyone else will really hit this
> issue or not.
> 
> We already have a few allocators (dma buf and an egl one). If they can fail
> then I'd guess it'd be better t backport since 1.6 is definitely not in the
> near future.

Thanks, I'll look at this. For your interest, there is already a EGL allocator part of gst-plugins-bad, and a dmabuf wrapper allocator part of gst-plugins-base. Any intention to improve this and share the effort ?
Comment 6 Nicolas Dufresne (ndufresne) 2014-07-30 13:52:19 UTC
In 1.4 now, thanks.

commit 57e3797e8891450bef6650862300ce688ee14ebd
Author: Mohammed Sameer <msameer@foolab.org>
Date:   Wed Jul 30 15:46:22 2014 +0300

    bufferpool: Add missing error checking to default_alloc_buffer()

    default_alloc_buffer() calls gst_buffer_new_allocate() but does not check
for
    failed allocation.

    This patch makes default_alloc_buffer() return an error (GST_FLOW_ERROR) if
    buffer allocation fails.

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