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 690197 - alsasrc: gets stuck in infinite loop if usb audio device is disconnected while being used
alsasrc: gets stuck in infinite loop if usb audio device is disconnected whil...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal major
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-12-14 05:43 UTC by Sun
Modified: 2018-01-22 11:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
logs (925.08 KB, application/octet-stream)
2012-12-14 05:43 UTC, Sun
  Details
[0.10] gstreamer-core (2.52 KB, patch)
2012-12-22 03:11 UTC, Sun
reviewed Details | Review
[0.10] gst-plugins-base (5.63 KB, patch)
2012-12-22 03:14 UTC, Sun
reviewed Details | Review

Description Sun 2012-12-14 05:43:20 UTC
Created attachment 231539 [details]
logs

i am facing problem using alsasrc .

i have a pipeline with alsasrc device=<> ! alsasink , when i disconnect my device , my system goes to wait indefinetly and never comes out of *set_state() to NULL funcion.

Attaching the logs for further reference.

After debugging found alsasrc is locking in  read function even if read gives error.

help me on if i do some wrong.
Comment 1 Sun 2012-12-14 08:09:33 UTC
and my thread blocks in :


Thread 1 (Thread 0xb3053780 (LWP 396))

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S line 145
  • #2 _L_lock_758
    from /lib/libpthread.so.0
  • #3 __pthread_mutex_lock
    at pthread_mutex_lock.c line 65
  • #4 gst_alsasrc_reset
    at gstalsasrc.c line 841
  • #5 gst_audioringbuffer_stop
    at gstaudiosrc.c line 460
  • #6 gst_ring_buffer_stop
    at gstringbuffer.c line 1315
  • #7 gst_ring_buffer_release
    at gstringbuffer.c line 903
  • #8 gst_base_audio_src_change_state
    at gstbaseaudiosrc.c line 1136
  • #9 gst_element_change_state
    at gstelement.c line 2761
  • #10 gst_element_set_state_func
    at gstelement.c line 2717
  • #11 gst_element_set_state
    at gstelement.c line 2618
  • #12 gst_bin_element_set_state
    at gstbin.c line 2209
  • #13 gst_bin_change_state_func
    at gstbin.c line 2518
  • #14 gst_pipeline_change_state
    at gstpipeline.c line 482
  • #15 gst_element_change_state
    at gstelement.c line 2761
  • #16 gst_element_continue_state
    at gstelement.c line 2444
  • #17 gst_element_change_state
    at gstelement.c line 2805
  • #18 gst_element_set_state_func
    at gstelement.c line 2717
  • #19 gst_element_set_state
    at gstelement.c line 2618

Comment 2 Tim-Philipp Müller 2012-12-14 12:16:24 UTC
I haven't looked at the log or code, but this issue does sound familiar, it might be fixed in git / 1.0.

Could you test whether you can still reproduce this with GStreamer 1.x ?
Comment 3 Sun 2012-12-15 05:01:18 UTC
is Application using 10.36 can use 1.0 without any changes ?
Comment 4 Sun 2012-12-15 05:56:01 UTC
Hi Tim , currently on our system we can't upgrade to 1.0 , please help be with  which patch or branch might fixed the problem , i can merge them to gst 10.36 and test.
Comment 5 Tim-Philipp Müller 2012-12-15 15:46:10 UTC
I was thinking of bug #614545 actually, but should be fixed already.

For what it's worth, you can install 1.0 in parallel with 0.10 for testing purposes. The two versions won't affect each other.

I can reproduce this bug with git master.
Comment 6 Tim-Philipp Müller 2012-12-16 12:36:18 UTC
commit 3d5a78e67a70194f3724b0d0c4f213681283eecf
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Sat Dec 15 19:36:56 2012 +0000

    alsa: post error message when audio device disappears
    
    Don't loop forever if an USB audio device gets disconnected
    while in use. Post an error message instead. This is not
    enough yet though, we still need to make the base class
    and/or the ring buffer bail out.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=690197

This is not enough yet though.
Comment 7 Tim-Philipp Müller 2012-12-17 20:55:07 UTC
commit df6031f7c656489f665d01fb629315cf50f09536
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Mon Dec 17 20:32:52 2012 +0000

    alsasrc: return negative value on read error
    
    Otherwise baseaudiosrc won't go into the error code path.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=690197

commit 68f366a8d37e5fb71106869b41911a749382143c
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Mon Dec 17 20:28:12 2012 +0000

    audiobasesrc: bail out if subclass posts an error
    
    Use new ringbuffer ERROR state to make all the various
    threads bail out correctly when the subclass posts an
    error. It's a bit iffy to communicate this properly
    between the different bits of code.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=690197

commit 4f49c7a33ba32cf1b30c4023570b241c24babd1a
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Mon Dec 17 20:26:33 2012 +0000

    audioringbuffer: add GST_AUDIO_RING_BUFFER_STATE_ERROR state
    
    API: GST_AUDIO_RING_BUFFER_STATE_ERROR
    
    https://bugzilla.gnome.org/show_bug.cgi?id=690197


Not trivial to backport to 0.10 I'm afraid, since there's no GstElementClass::post_message function there. You'd have to take the code from the == MESSAGE ERROR block in post_message, and put it before/after the GST_ELEMENT_ERROR call in device_disconnected: in alsasrc or so. Good luck!
Comment 8 Sun 2012-12-22 03:11:48 UTC
Created attachment 232102 [details] [review]
[0.10] gstreamer-core
Comment 9 Sun 2012-12-22 03:13:58 UTC
I back ported wih post_message in GstElementClass and still its getting stuck in infinite loop.

Diff , attached for modification.
Comment 10 Sun 2012-12-22 03:14:45 UTC
Created attachment 232103 [details] [review]
[0.10] gst-plugins-base
Comment 11 Sun 2012-12-22 04:03:57 UTC
Hangs in :


Thread 1 (LWP 832)

  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/libc.so.6
  • #2 g_poll
    from /lib/libglib-2.0.so.0
  • #3 ??
    from /lib/libglib-2.0.so.0
  • #4 g_main_loop_run
    from /lib/libglib-2.0.so.0
  • #5 gst_bus_poll
    at gstbus.c line 1078
  • #6 event_loop
    at gst-launch.c line 623
  • #7 main
    at gst-launch.c line 1157

Comment 12 Tim-Philipp Müller 2012-12-22 10:27:14 UTC
0.10 is not maintained any longer, sorry.

Please test with git master (1.1.0) and see if the issue is fixed there first.
Comment 13 Sun 2013-04-06 09:11:13 UTC
after trying with master stil hang is seen.
Comment 14 Tim-Philipp Müller 2013-04-06 09:21:39 UTC
Please  attach a GST_DEBUG=*audio*:6,*alsa*:6,*src*:6 debug log and a stack trace of all threads with full debugging symbols, as requested on IRC.
Comment 15 Sun 2013-04-07 11:03:33 UTC
http://paste.ubuntu.com/5685825/
Comment 16 Sun 2013-04-07 12:43:25 UTC
Logs with fakesink.

http://paste.kde.org/717782/
Comment 17 Sun 2013-04-08 11:41:21 UTC
i found read() function is blocking , though device is opened in non_block mode but when prepare_read() it make it to block and it hangs if there is no data to be filled

so will there be any problem if i change alsasrc_prepare() to prepare read in non_block mode ?

Patch is as below.

http://paste.kde.org/718544/