On Wed, Sep 12, 2012 at 12:21 PM, Josh Blum
<address@hidden> wrote:
Just curious. Are you trying to implement a discontinuous streaming
model? Or are you looking for a way to control start time but still
continuous?
I think I want a way to control start time but still continuous. But I may know not so much about discontinuous streaming. What is the difference between the discontinuous streaming and the finite acquisition?
>
> case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
> //Assume that the user called stop() on the flow graph.
> //However, a timeout can occur under error conditions.
> if (_start_on_demand == true)
> //Start is first called by the gr_block_executor
> //We are still waiting for the mannual start command
> return work(noutput_items, input_items, output_items);
>
> return WORK_DONE;
>
FWIW, the current source block actually has a change to loop forever in
the work function until the thread interrupted. This is because source
blocks in gnuradio cannot return from the work function without
producing. Although, it would be very nice for blocks like uhd source,
udp source, and probably a few others that block on input IO to be able
to return from work without producing.
>
> Unfortunately, although the new code passes the build, the behavior is
> still strange, for below python code:
> tb.start() # start flow graph
> time.sleep(10) # wait 10 seconds to start the streaming
> tb.source.u.start()
>
> Now the streaming is not started when tb.start() is called in the
> beginning. But when 10 seconds sleep ends, the flow graph crashes by
> reporting: "***glibc detected *** python: corrupted double-linked list:
> 0x00007fcb640011c0", apparently on calling the
> usrp_source.start() manually. I seems some memory issue happens, but in
> usrp_source.start(), it just tries send a command to USRP.
>
> I suppose the streaming start and stop should be used easily but not know
> why such kind of problem happens.
> Still debugging it, any comments are appreciated.
>
I guess its necessary to determine which line of c++ is actually causing
the error.
One thing you may check, since you are stopping the first start from
happening, is the rx streamer still getting created? The rx streamer
needs to be created before work is called. You may want to check if the
streamer is created so 1) you can avoid re-allocation, 2) stop work from
calling into null streamer
Thanks for this indication, I will check if the incorrect object operation.
-josh