Expl me this

Why should:

http://www.sbrac.org/files/testme.py
http://www.sbrac.org/files/testme.grc

Be causing Gnu Radio to attemp to allocate 16GB of virtual memory?
Under what drug-induced fantasy should a straight-line
FFT (admittedly a chunky FFT) buffer be ballooned out by a factor of
1000, when the FFT size is a power of 2!

I realize that only half of that space actually maps to physical
memory, but 8GB for an FFT of order 2**23 is decidedly piggy.

Furthermore, it always provokes a fatal error, no matter which “factory”
I use for buffer allocation:

gr_vmcircbuf_mmap_shm_open: invalid size = -795873280
gr_buffer::allocate_buffer: failed to allocate buffer of size 15999996
KB
terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc

Because it looks like that buffer size is 32-bits unsigned, regardless
of the underlying system architecture (I’m on an x86_64 machine).


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On 12/05/2010 06:25 PM, Marcus D. Leech wrote:

I realize that only half of that space actually maps to physical
Because it looks like that buffer size is 32-bits unsigned, regardless
of the underlying system architecture (I’m on an x86_64 machine).

Oh, never mind. Mixed-mode math in Python causing non power-of-2 FFT
size. Sorry guys. Never mind.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium