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 679145 - gst_buffer_copy and gst_buffer_make_writable semantics
gst_buffer_copy and gst_buffer_make_writable semantics
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal major
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 678384 680091
 
 
Reported: 2012-06-29 14:41 UTC by Mark Nauwelaerts
Modified: 2012-07-19 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to core unit test to demonstrate described semantics (1.69 KB, patch)
2012-06-29 14:42 UTC, Mark Nauwelaerts
committed Details | Review
tests: gstbuffer: extend buffer copy test (1.33 KB, patch)
2012-07-18 13:37 UTC, Mark Nauwelaerts
none Details | Review

Description Mark Nauwelaerts 2012-06-29 14:41:31 UTC
In 0.10, both functions return a buffer that is "independent" in the sense that writing into it will not affect the buffer it originated from.

However, attached patch to gstbuffer core unit test shows that is no longer the case at present, and memory of the new buffer is still shared with the original one.

While this may be very much intentional, it is considerably surprising to say the least, whether by itself or in the breaking with 0.10.  It is also not documented (clearly afaics).  And if this is as it should be and remain, then we are missing on utility function (or whatever) that will really come up with an independent copy (in 0.10 tradition).
Comment 1 Mark Nauwelaerts 2012-06-29 14:42:45 UTC
Created attachment 217628 [details] [review]
Patch to core unit test to demonstrate described semantics
Comment 2 Wim Taymans 2012-07-03 15:19:54 UTC
Some preliminary ideas:

http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=memory-lock
Comment 3 Wim Taymans 2012-07-04 15:48:10 UTC
Moved the lock/unlock to miniobject in the branch now.
Comment 4 Wim Taymans 2012-07-05 10:19:49 UTC
Merged and fixed in git now.
Comment 5 Mark Nauwelaerts 2012-07-18 13:37:38 UTC
Created attachment 219124 [details] [review]
tests: gstbuffer: extend buffer copy test

Looks like we may still be having some problems in coming up with really
independent buffer copies, so re-opening this.

Reading code suggests this can indeed happen in the sequence:
* locking EXCLUSIVE some fresh memory
* mapping it WRITE
* then making a buffer copy, adding another EXCLUSIVE lock
* mapping it WRITE again

Attached patch extends the unit test to illustrate/test this.
Comment 6 Mark Nauwelaerts 2012-07-18 14:08:28 UTC
Somewhat related, w.r.t. order of locking EXCLUSIVE / WRITE, also note that gst_buffer_map_range might well end up with a new piece of memory (from gst_memory_make_mapped) which is then already mapped (e.g. WRITE) and which will only then be accepted as buffer memory (and thereby locked EXCLUSIVE).
Comment 7 Wim Taymans 2012-07-19 11:25:29 UTC
commit fd23640001495bfb8529466a14c930211cc1809a
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Thu Jul 19 13:20:27 2012 +0200

    miniobject: refuse write when object is shared
    
    In all cases, refuse to write an object when it is shared by more than one
    object (also when the object was locked before).
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=679145

commit 8620352efcf82650602f2bd16226fa8bb342c58b
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Wed Jul 18 15:21:33 2012 +0200

    tests: gstbuffer: extend buffer copy test