Re: [Discuss-gnuradio] Trouble with latest GIT of Gnu Radio

[Tom Rondeau]

On Mon, Jul 5, 2010 at 12:27 PM, Marcus D. Leech <address@hidden> wrote:
> On 07/05/2010 12:03 PM, Tom Rondeau wrote:
>> On Sat, Jul 3, 2010 at 8:17 PM, Marcus D. Leech <address@hidden> wrote:
>>
>>> Environment: 3 different computers, all running F12 with all latest updates
>>> Both USRP2 and USRP1
>>>
>>> Latest GIT
>>>
>>> A segfault is provoked in gr_sync_decimator.cc:64    when you have an
>>> FFT filter, and change its size
>>>  at runtime.
>>>
>>> Doesn't matter which circbuf factory I'm using, or which of my 3 systems
>>> (two are x86_64 and one is x86).
>>>
>>> Doesn't matter whether the FFT filter is "big" or little.  Increasing
>>> one from 2 taps to 128 taps was enough
>>>  to cause a segmentation fault.
>>>
>>> Doesn't seem to matter whether you're increasing the size, or decreasing it.
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>>>
>>
>> Marcus,
>>
>> I can't seem to replicate this problem on my Ubuntu 10.04 64-bit machine.
>>
>> I created a signal, fft filter (ccc), and a file sink with a
>> threshold, connected them, and ran the flow graph. To run it, I used
>> this, where mytb is the top_block class.
>>
>> def main():
>>     taps0 = gr.firdes.low_pass_2(1, 1, 0.1, 0.1, 60)
>>     taps1 = gr.firdes.low_pass_2(1, 1, 0.01, 0.01, 60)
>>
>>     print "Setting start taps (ntaps = %d)" % (len(taps0))
>>     tb = mytb(taps0)
>>     tb.start()
>>
>>     time.sleep(0.5)
>>
>>     print "Setting new taps (ntaps = %d)" % (len(taps1))
>>     tb.fftfilt.set_taps(taps1)
>>
>>     time.sleep(0.5)
>>
>>     tb.stop()
>>     tb.wait()
>>
>>
>> The initial taps have length 27 and the new taps (taps1) have length
>> 273. I also tried it with both complex in/out/taps and float
>> in/out/taps.
>>
>> Is there something else that I'm missing?
>>
>> Tom
>>
>>
>>
> Tom:
>
> Just attached a tiny little file that generates the problem.
>
> USRP source, FFT filter, null sink.
>
> There's a graphical control that controls the transition width of the
> filter parameters.  Changing that control
>  provokes the issue immediately.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org

Unfortunately, I don't have a way to test this with a USRP right now,
so what I did was use a noise source and a throttle block instead of
the USRP source and it worked fine. Could you try it without the USRP
block and see what happens? It'd be strange if this was the cause, but
worth trying.

Tom