Re: [Discuss-gnuradio] seg fault in volk_32f_s32f_multiply_32f_a_sse gnuradio v 3.6.1

[Tom Rondeau]

On Wed, Sep 5, 2012 at 10:05 AM, Tom Rondeau <address@hidden> wrote:
> On Tue, Sep 4, 2012 at 9:01 PM, ikjtel <address@hidden> wrote:
>>
>>
>>> Yes, looks like it. But it's an Atom, which might change things. I
>>
>>> know we had some issues on Atom's before, but I thought that we worked
>>> them out. I'll be interested to see how cmake reports the architecture
>>> checks for VOLK here.
>>
>> Hi Tom
>>
>> I've made some further progress, and this may be premature, but I'll go so 
>> far as to say we can rule this out entirely.
>>
>> Here's a strawman theory - criticism of the theory is invited, shooting it 
>> down would be welcomed ; )
>>
>> Our app uses lots of disconnect() and connect() calls because our appetite 
>> for widgets is bigger than the CPU available.  Also, since the widgets are 
>> tab-selectable there is only one widget visible at a time.  So when the user 
>> hits a tab we call disconnect and connect (surrounded by lock() / unlock() 
>> of course) in order to dynamically create a flow graph that connects up all 
>> the elements needed by that tab (and disconnects the elements, filters, 
>> demods, FFT's and other blocks that aren't needed by this tab, to conserve 
>> CPU.
>>
>> The theory is that this is "messing up" the boundary alignments of the 
>> operands to the SSE instructions, making them no longer properly aligned, 
>> resulting in a GPF.
>>
>> Here's the minimal python app , it seg faults in volk 100% reliably for me.  
>> If the call to shuffle() is removed, the script does not crash.
>>
>> Max
>
> Max,
>
> That's not a bad theory as I've run into the same situation before. I
> had a fix for that, though, back before the release of 3.6.0. It's
> possible that it's more complicated, though. I'll use your script to
> see if I can do more to figure it out.
>
> Tom
>
>
>> p.s. kindly let me know if this code isn't properly machine-readable
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> #!/usr/bin/env python
>> import math
>> import time
>> from gnuradio import gr, gru, audio, eng_notation, blks2, optfir
>>
>> class app_top_block(gr.top_block):
>>     def __init__(self):
>>         gr.top_block.__init__(self, "mhp")
>>
>>         self.source = gr.sig_source_f(48000, gr.GR_TRI_WAVE, 1.0, 1.0, 0)
>>         self.amp = gr.multiply_const_ff(65.0)
>>         self.sink = gr.null_sink(gr.sizeof_float)
>>
>>         self.connect(self.source, self.amp, self.sink)
>>         self.amp_connected = True
>>
>>     def shuffle(self):
>>         self.lock()
>>         if self.amp_connected:
>>             self.disconnect(self.source, self.amp, self.sink)
>>             self.connect(self.source, self.sink)
>>         else:
>>             self.disconnect(self.source, self.sink)
>>             self.connect(self.source, self.amp, self.sink)
>>         self.amp_connected = not self.amp_connected
>>         self.unlock()
>>
>> if __name__ == "__main__":
>>     tb = app_top_block()
>>     tb.start()
>>     while True:
>>         time.sleep(0.1)
>>         tb.shuffle()
>>

Max,

I believe I have fixed your problem. Check out the latest master
branch (it's commit 77035b5d188be9e5dcd6731b1a58a4ce47451bde).

I was using your demo code that you posted here as a test, and it's
now working fine for me now.

Tom