[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Memory allocation woes
From: |
Marcus D. Leech |
Subject: |
Re: [Discuss-gnuradio] Memory allocation woes |
Date: |
Tue, 29 Jun 2010 14:16:24 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 |
On 06/29/2010 01:37 PM, Eric Blossom wrote:
> The place to add some debugging outout would be
> gr_flat_flowgraph.cc::allocate_buffer. Something like:
>
> std::cout << "allocate_buffer " << block
> << " nitems " << nitems << " item_size " << item_size <<
> std::endl;
>
>
> For the case of the 6M bin FFT, I could see us getting to
>
> 6M * sizeof(gr_complex) * 2 * 2 --> 192MB. Not that big.
>
>
> Add the debugging output and let us know what you find.
>
>
allocate_buffer complex_to_mag(1) nitems 4 item_size 25000000
gr_buffer::allocate_buffer: warning: tried to allocate
4 items of size 25000000. Due to alignment requirements
64 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument
gr_buffer::allocate_buffer: failed to allocate buffer of size 1562500 KB
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This is the complex_to_mag(1) right after the HUGE FFT.
That item size must be the size of the *output* vector (6M *
sizeof(float) + 'slop'??).
Now, see what happens? It's rounding up that 4 items to 64 items, which
is ballooning out
the request size considerably!!
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org