Dead lock

[kirat68]

Hello there,

Thank you for providing this useful code!

I am experiencing a dead lock when the destructor of sdrplay3 is called and after the function "void rsp_impl::stream_callback" acquired the lock. In this situation the call of the API function "sdrplay_api_ReleaseDevice" get blocked and just an api server restart can remove it what is very problematic.

You can reproduce it try it in the python interpreter as follow:

import sdrplay3
sdr = sdrplay3.rsp1a('',s = sdrplay3.rsp1a('', sdrplay3.stream_args( output_type='fc32', channels_size=1 )) sdrplay3.stream_args( output_type='fc32', channels_size=1 ))
del sdr

The destructor will not return.

Removing "ring_buffer.overflow.wait(lock," solves apparently the problem.

If you could help to resolve this issue, it would be great.

Thank you for your attention !!!

[fventuri]

@kirat68 - thanks for the nice words and for reporting this problem.

I think you might have incorrectly cut&pasted the Python code in your example, because when I tried to run it here a minute ago, it failed with 'syntax error' (and looking at the actual code it seems that part of it was pasted twice, or something like that).

Franco

[kirat68]

Oh sorry true !!!
Here is the correct piece of code:

import sdrplay3
sdr = sdrplay3.rsp1a('', sdrplay3.stream_args( output_type='fc32', channels_size=1 ))
sdr.start()
del sdr

Regards

Tarik

[fventuri]

Thanks Tarik for the correction.
I was able to reproduce your problem here too.

I have to start working now, but I'll take a look at what happens after dinner tonight, and I'll let you know what I find out.

Franco

[kirat68]

Obrigado !!!

[fventuri]

De nada Tarik!

You were correct about the problem being with the ring_buffer.overflow condition variable; however that wait for the lock cannot be removed otherwise the callback threads might overwrite the content of the ring buffer before the thread that runs the GNU Radio work function has time to retrieve the samples.

What I did (see this commit: da33df3) is to add a couple of notify for those condition variables in the stop() method, right after the SDRplay API function sdrplay_api_Uninit() is called, so those threads will resume and terminate shortly thereafter (after sdrplay_api_Uninit() the RSP device stops streaming, so sdrplay_api_ReleaseDevice() will be able to complete because there are no hanging threads).

I just pushed the new code to the branch let_callback_threads_terminate_after_stop: https://github.com/fventuri/gr-sdrplay3/tree/let_callback_threads_terminate_after_stop - using this new code your example Python script terminates as expected.

Please give it a try and let me know if it works for you too.

Franco

[kirat68]

Bom dia Franco !

Thank you for your instantaneous reaction :-)
I tried your fix and it solves the deadlock problem, but I am experiencing something new that should not happen.
When removing hardly the SDR by pulling the USB cable, sdrplay3 seems to continue streaming iq data. The expected behavior should be not streaming. To better see what is going on, I attached 2 screen shots of the gnuradio frequency display.

Tarik

When SDR running

After pulling out SDR from USB and not stopping at all.

[fventuri]

@kirat68 - sorry for making you wait; I finally found some time tonight to test what happens in that scenario (pulling the USB cable while the RSP is streaming).

I used this GRC flowchart (https://github.com/fventuri/gr-sdrplay3/blob/master/examples/FM-Receiver-SDRplay.grc)' in it I just replaced the source block with an RSPdx source block (because this is what I have connected to my PC right now).

I started streaming, everything good, then after about 20 seconds, I pulled the USB cable while the RSPdx was streaming. Immediately after that, GRC printed the following error message in the console:

gr::log :ERROR: rspdx0 - device removed

and it stopped streaming, as expected.

The code I am using for gr-sdrplay3 in this test is the code from the branch let_callback_threads_terminate_after_stop.

Franco

[kirat68]

No problem!

Thank you for this feed back.

I am confused now because I cannot reproduce it anymore but getting at hard USB unplug a segmentation fault in GRC. I will check this issue closer and open a new one if I can get more information relate it to sdrplay3.

But this is not related to the dead lock that I consider solved. Running a long long test right now but I am confident that you solved the issue. Thank you very much.

[fventuri]

@kirat68 - thanks for your feedback about the dead lock problem.

I just merged those changes into the master branch.

I am going to leave this issue open for a few days in case you notice more problems due to this change.

Franco