Re: [Discuss-gnuradio] Gnuradio locking up

On 22/11/11 11:02 AM, Rachel Kroll wrote:
> On Nov 22, 2011, at 7:56 AM, Marcus D. Leech wrote:
>
>
>> On 22/11/11 10:48 AM, Rachel Kroll wrote:
>>
>>> It's pretty easy to get wedged forever if you call lock and unlock a lot in conjunction with connect and disconnect. Sooner or later, you'll hit a race and things will get stuck.
>>>
>>> I have a simple reproduction case if anyone is interested. It'll hang reliably after a few dozen iterations.
>>>
>>>
>>>
>> That's the type of information that shouldn't be withheld from this
>> list, and by implication, the
>> developers. Don't assume that because you've found a
>> bug/unexpected-behaviour, that the developers
>> know about it, and are working on a fix.
>>
> It's come up a few times in the mailing list archives. The usual solution seems to be "add more sleeps", which of course is not a fix.
>
> Anyway, here's the reproduction case:
>
> #include <gnuradio/gr_file_sink.h>
> #include <gnuradio/gr_sig_source_f.h>
> #include <gnuradio/gr_hier_block2.h>
> #include <gnuradio/gr_io_signature.h>
> #include <gnuradio/gr_top_block.h>
>
> static void connect(gr_top_block_sptr block, gr_sig_source_f_sptr source,
> gr_hier_block2_sptr block2) {
> fprintf(stderr, "connect: calling lock, connect, unlock\n");
> block->lock();
> block->connect(source, 0, block2, 0);
> block->unlock();
> fprintf(stderr, "connect: done\n");
> }
>
> static void disconnect(gr_top_block_sptr block, gr_sig_source_f_sptr source,
> gr_hier_block2_sptr block2) {
> fprintf(stderr, "disconnect: calling block->lock\n");
> block->lock();
>
> fprintf(stderr, "disconnect: calling block->disconnect\n");
> block->disconnect(source, 0, block2, 0);
>
> fprintf(stderr, "disconnect: calling block->unlock\n");
> block->unlock(); // It usually hangs here.
>
> fprintf(stderr, "disconnect: done\n");
> }
>
> int main(int argc, char** argv) {
> // Inner block: block to sink.
> gr_hier_block2_sptr inner;
> inner = gr_make_hier_block2("inner",
> gr_make_io_signature(1, 1, sizeof(float)),
> gr_make_io_signature(0, 0, 0));
>
> gr_file_sink_sptr sink;
> sink = gr_make_file_sink(sizeof(float), "/dev/null");
> inner->connect(inner, 0, sink, 0);
>
> // Outer block: signal source to inner block.
> gr_top_block_sptr outer = gr_make_top_block("outer");
> gr_sig_source_f_sptr src = gr_make_sig_source_f(11025, GR_COS_WAVE,
> 400, .1, 0);
>
> // Hook it up and get it going.
> connect(outer, src, inner);
> outer->start();
>
> // Frob it until we die.
> while (true) {
> disconnect(outer, src, inner);
> fprintf(stderr, "\n\n------------------------\n\n");
>
> connect(outer, src, inner);
> }
>
> return 0;
> }
>
>
>
>
Thanks for this code snippet. Oh, and I read your "Forest for the
Trees" piece. Nice.

I've never had a big flow-graph that used dynamic topology reconfig,
because when I first started
using Gnu Radio back in 2005, the flow-graph topology had to be static
once started. So, I tend
to structure things based on that assumption, and generally don't run
into wedgies ever.

I've had flow-graphs that have run for *weeks*, and only died when a
power-failure tripped out the
entire computer.

So, clearly, the lock()/unlock()/connect()/disconnect() logic is subtly
broken. Parallelism tends to
break subtly, unfortunately.

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio