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 669611 - [0.11] wavparse: gst_adapter_push: assertion `GST_IS_ADAPTER (adapter)' failed
[0.11] wavparse: gst_adapter_push: assertion `GST_IS_ADAPTER (adapter)' failed
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.11.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-02-07 22:06 UTC by Peteris Krisjanis
Modified: 2012-02-12 17:03 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Python script for creating pipeline and playing it (485 bytes, text/x-python)
2012-02-07 22:08 UTC, Peteris Krisjanis 		Details

Description Peteris Krisjanis 2012-02-07 22:06:47 UTC 
This is actual on 0.11 branch, dated 07.02.2012

It seems when doing wav parsing gst_wavparse_chain tries to push adapter, but it's 0x0, so when gst_adapter_push checks if it's really adapter, it fails.

For reproducing this use attached script.

It ends with messages like this:
** CRITICAL **: gst_adapter_push: assertion `GST_IS_ADAPTER (adapter)' failed

** CRITICAL **: gst_adapter_available: assertion `GST_IS_ADAPTER (adapter)' failed

gdb with G_DEBUG=fatal-criticals gives me this:

+ Trace 229628

  • #0 g_logv
    at gmessages.c line 765
  • #1 g_log
    at gmessages.c line 792
  • #2 g_return_if_fail_warning
  • #3 gst_adapter_push
    at gstadapter.c line 320
  • #4 gst_wavparse_chain
    at gstwavparse.c line 2093
  • #5 gst_pad_chain_data_unchecked
    at gstpad.c line 3330
  • #6 gst_pad_push_data
    at gstpad.c line 3533
  • #7 gst_type_find_element_loop
    at gsttypefindelement.c line 1076
  • #8 gst_task_func
    at gsttask.c line 314
  • #9 default_func
    at gsttaskpool.c line 70
  • #10 g_thread_pool_thread_proxy
    at gthreadpool.c line 317
  • #11 g_thread_proxy
    at gthread.c line 801
  • #12 start_thread
    from /lib/libpthread.so.0
  • #13 clone
    from /lib/libc.so.6 






Comment 1


Peteris Krisjanis





          2012-02-07 22:08:10 UTC
        



Created attachment 207029 [details]
Python script for creating pipeline and playing it

Just provide wav file of your choice.






Comment 2


Vincent Penquerc'h





          2012-02-12 12:31:38 UTC
        



I cannot reproduce this, either with 0.11 as of a few weeks back, nor from today.
I did not use quite your sample though (not having the right python bindings).
Can you repro this with current git, with your python code ?
If yes, can you repro it with: gst-launch-0.11 filesrc ! decodebin ! audioconvert ! fakesink ?
The latter works fine here (also with a queue before decodebin).






Comment 3


Peteris Krisjanis





          2012-02-12 16:03:34 UTC
        



Strangely, current 0.11 branch is fixed with this. This error accoured somehwere last week (I tried it on two boxes). I rebuilt my jhbuild on Wednesday, and it was gone.

Anyway, it seems fixed now. Sorry about disturbance :)






Comment 4


Tim-Philipp Müller





          2012-02-12 16:15:02 UTC
        



It may have had to do with the mode switching issues fixed in typefind recently.






Comment 5


Wim Taymans





          2012-02-12 17:03:28 UTC
        



Yep, fixed with this:

commit 27d639ec09d6853a374d4dd8b548f2a1dbd47de6
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Feb 8 14:32:01 2012 +0100

    typefind: fix race in pad mode change
    
    Fixes #668909 and presumably also #669483