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 620197 - [xvimagesink] occasional buffer metadata writable warnings
[xvimagesink] occasional buffer metadata writable warnings
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-31 23:21 UTC by Tim-Philipp Müller
Modified: 2011-06-26 19:03 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
xvimagesink: Make sure that the buffer metadata is writable before changing it (1.12 KB, patch)
2010-06-01 08:55 UTC, Sebastian Dröge (slomo) 		rejected Details | Review

Description Tim-Philipp Müller 2010-05-31 23:21:58 UTC 
When playing a movie, somewhere in the middle:


Program received signal SIGINT, Interrupt.
0x00007ffff16fc123 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=200) at ../sysdeps/unix/sysv/linux/poll.c:87
87	../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
	in ../sysdeps/unix/sysv/linux/poll.c
(gdb) break g_logv if log_level == G_LOG_LEVEL_WARNING
Breakpoint 1 at 0x7ffff25adb50: file /tmp/buildd/glib2.0-2.24.1/glib/gmessages.c, line 430.
(gdb) c
Continuing.
[Thread 0x7fffd1a44710 (LWP 4284) exited]

+ Trace 222178

Thread 140736830711568 (LWP 4281)

  • #0 IA__g_logv
    at /tmp/buildd/glib2.0-2.24.1/glib/gmessages.c line 430
  • #1 IA__g_log
    at /tmp/buildd/glib2.0-2.24.1/glib/gmessages.c line 569
  • #2 IA__g_warn_message
  • #3 gst_buffer_set_caps
    at gstbuffer.c line 490
  • #4 gst_xvimagesink_buffer_alloc
    at xvimagesink.c line 2604
  • #5 gst_base_sink_pad_buffer_alloc
    at gstbasesink.c line 598
  • #6 gst_pad_buffer_alloc_unchecked
    at gstpad.c line 2900
  • #7 gst_pad_alloc_buffer_full
    at gstpad.c line 2977
  • #8 gst_pad_buffer_alloc_unchecked
    at gstpad.c line 2900
  • #43 alloc_output_buffer
    at gstffmpegdec.c line 917
  • #44 gst_ffmpegdec_get_buffer
    at gstffmpegdec.c line 1028
  • #45 alloc_frame_buffer
    at libavcodec/mpegvideo.c line 196
  • #46 ff_alloc_picture
    at libavcodec/mpegvideo.c line 238
  • #47 MPV_frame_start
    at libavcodec/mpegvideo.c line 924
  • #48 ff_h263_decode_frame
    at libavcodec/h263dec.c line 617
  • #49 avcodec_decode_video2
    at libavcodec/utils.c line 586
  • #50 avcodec_decode_video
    at libavcodec/utils.c line 572
  • #51 gst_ffmpegdec_video_frame
    at gstffmpegdec.c line 1754
  • #52 gst_ffmpegdec_frame
    at gstffmpegdec.c line 2231
  • #53 gst_ffmpegdec_chain
    at gstffmpegdec.c line 2646
  • #54 gst_pad_chain_data_unchecked
    at gstpad.c line 4132
  • #55 gst_pad_push_data
    at gstpad.c line 4361
  • #56 gst_single_queue_push_one
    at gstmultiqueue.c line 919
  • #57 gst_multi_queue_loop
    at gstmultiqueue.c line 1101
  • #58 gst_task_func
    at gsttask.c line 271
  • #59 g_thread_pool_thread_proxy
    at /tmp/buildd/glib2.0-2.24.1/glib/gthreadpool.c line 315
  • #60 g_thread_create_proxy
    at /tmp/buildd/glib2.0-2.24.1/glib/gthread.c line 1893
  • #61 start_thread
    at pthread_create.c line 300
  • #62 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #63 ?? 


(gdb) print *buffer
$1 = {mini_object = {instance = {g_class = 0xb41070}, refcount = 2, flags = 0, _gst_reserved = 0x0}, 
  data = 0x7fffd11f3000 "0001222334456667667888889;;;:778;=?@@?ABDDEFGGHHFFFGGHHILLKKLLLNMMMNOOOPPQRRSSTUTUWXXZZZ[\\^^_acdddefgf_YZekmnppprsttstvxwxwyyz|~}~~\200\201\202\202\201\202\203\204\205\206\206\207\207\212\211\212\211\212\213\214\214\216\216\217\217\217\220\221\222\220\220\222\221\223\217\210cFCA@?>=<<;::::999988889999::::;:"..., size = 329472, timestamp = 613904958333, duration = 41708333, 
  caps = 0x1925800, offset = 14719, offset_end = 18446744073709551615, malloc_data = 0x0, free_func = 0x7ffff25ac2d0 <IA__g_free>, parent = 0x0, _gst_reserved = {0x0, 0x0}}
Comment 1 Sebastian Dröge (slomo) 2010-06-01 08:55:31 UTC 
Created attachment 162438 [details] [review]
xvimagesink: Make sure that the buffer metadata is writable before changing it

Fixes bug #620197.
Comment 2 Sebastian Dröge (slomo) 2010-06-01 08:58:04 UTC 
This should fix it but I'm not sure if this interferes somehow with the xvimagesink buffer subclassing. Also, the buffers should all have a refcount of 1 at that point because they're either newly allocated or from the freed xvimagesink buffer pool.
Comment 3 Benjamin Otte (Company) 2010-06-01 14:05:09 UTC 
Because of that last sentence I'd reject this patch. The ref count must be 1 and working around that case does solve the warning, but not the bug.
That said, I have absolutely no idea why the refcount would be != 1. For that we'd need more refcount debugging output.

A rough guess is a race somewhere, where some code refs the buffer immediately after unreffing it. Is that thing reproducible? Does it only happen for certain types of files?
Comment 4 Sebastian Dröge (slomo) 2011-05-09 09:33:10 UTC 
Setting as NEEDINFO because there's not enough information to debug this.
Comment 5 Tim-Philipp Müller 2011-06-26 19:03:35 UTC 
Well, it still happens occasionally, and almost always at the end of a movie. Hard to believe no one else has seen this. But sure, not enough info. Probably some refcounting issue in gst-ffmpeg.