Solved my problem; I wasn’t deleting the float arrays in the sink. Silly 
mistake.

Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241

On Mar 27, 2014, at 10:27 AM, Tommy Tracy II <[email protected]> wrote:

> Dear Marcus,
> 
>       Thank you. I will explain my setup and system below
>       I am running Ubuntu 13.04, kernel: 3.8.0-35-generic in a VM.
>       I am using a pybombs-installed GR version v3.7.2.1-195-g19d111e2.
> 
> The description below is a small component of my overall system design; what 
> I’m seeking to do is include a multiple-producer, multiple-consumer queue 
> into the flow graph. The c++ code for this test program is here:
>       Source: 
> https://github.com/tjt7a/GR-Router/blob/master/apps/transparent.cc
> 
> The flow graph:
>       [WAVFILE SOURCE] - [THROTTLE] - several[FFT/IFFT]s - [THROUGHPUT] - 
> [OUTPUT QUEUE SINK]  —|QUEUE|— [OUTPUT QUEUE SOURCE] - [FILE SINK]
>       It may seem unnecessary to include a QUEUE in the case about, but I am 
> benchmarking having a QUEUE vs. not using one.
> 
> Explaining the different blocks:
>       [FFT/IFFT] block is a hierarchical dummy load. It accepts a stream of 
> floats, vectorizes the stream, does a forward FFT, then a reverse FFT, and 
> de-vectorizes.
>       Source: https://github.com/tjt7a/GR-Router/blob/master/apps/fft_ifft.cc
> 
>       [THROUGHPUT] block is a transparent block that returns the running 
> average throughput; it’s basically the compliment of the [THROTTLE BLOCK] 
> (existing gnu radio::blocks)
>       Source: 
> https://github.com/tjt7a/GR-Router/blob/master/lib/throughput_impl.cc
> 
>       **This is where I’m getting the error message**
>       [OUTPUT QUEUE SINK] block accepts a stream of floats, packages them 
> into a series of 1024-float vectors, tacks on a message type, message index, 
> and message size, and pushes the address of these messages onto the lock free 
> queue.
>       Source: 
> https://github.com/tjt7a/GR-Router/blob/master/lib/queue_sink_impl.cc (I 
> would ignore the if(preserve) for now) 
> 
>       |QUEUE|: This is a boost::lockfree::queue. This queue supports multiple 
> producers and consumers. It dynamically grows in size. (unless I were to 
> constrain the size)
>       Source: 
> http://www.boost.org/doc/libs/1_53_0/doc/html/boost/lockfree/queue.html
> 
>       [OUTPUT QUEUE SOURCE] block is basically the compliment of the [OUTPUT 
> QUEUE SINK] block. It pops message addresses off of the queue, reads headers, 
> and dumps the data on the output.
>       Source: 
> https://github.com/tjt7a/GR-Router/blob/master/lib/queue_source_impl.cc ( I 
> would ignore the if(preserve) and if(order) cases for now … I plan to use a 
> heap in the future for ordering)
> 
> 
> Tommy James Tracy II
> Ph.D Student
> High Performance Low Power Lab
> University of Virginia
> Phone: 913-775-2241
> 
> On Mar 27, 2014, at 4:41 AM, Marcus Müller <[email protected]> wrote:
> 
>> Signed PGP part
>> Hi Tommy,
>> 
>> as this, I haven't seen it.
>> However, this is really guessing - could you supply a little more
>> information (Platform, GR version, OS version etc) and try to do a
>> backtrace?
>> Since you have problems with low-level and scheduler-related code (and
>> if I remember correctly, not the first time), a little information on
>> your application as whole and in detail how you use that block would
>> obviously be of help ;)
>> 
>> Greetings,
>> Marcus
>> 
>> On 27.03.2014 06:09, Tommy Tracy II wrote:
>> > Dear Gnuradio Community,
>> >
>> > I ran my GNURADIO program and got the following error message:
>> >
>> > thread[thread-per-block[357]: <block queue_sink (4)>]:
>> > std::bad_alloc
>> >
>> > This looks like a memory allocation problem with the scheduler. Has
>> > anyone seen this before? What would cause this?
>> >
>> > Sincerely, Tommy James Tracy II Ph.D Student High Performance Low
>> > Power Lab University of Virginia Phone: 913-775-2241
>> >
>> >
>> >
>> >
>> > _______________________________________________ Discuss-gnuradio
>> > mailing list [email protected]
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> 
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to