Re: [Discuss-gnuradio] Stable on Linux, many crashes on Windows and OS X

[Stefan Oltmanns]

Hi Michael,

I was able to fix the problem with an extraordinary ugly hack:

I added a global mutex to GnuRadio and protect
gr::filter::freq_xlating_fir_filter_ccf_impl::build_composite_fir with
it, so only one instance can call
gr::filter::kernel::fir_filter_ccc::set_taps at the time.

Stable now on both OS X and Windows. I think it´s definitely a bug in
Volk, or is Volk not supposed to be thread-safe?
Can you confirm that bug?

Why it worked on Linux before, I´m not sure, either other code in
GnuRadio is used or the scheduler of the OS is somehow different, so
that the problem never occurred.

Thank you very much
Stefan

Am 05.08.2014 15:58, schrieb Michael Dickens:
> Hi Stefan - OK; cool.  Loading up that example, it runs for quite a long time 
> as you describe, before crashing.  Here's the backtrace from gdb when it 
> crashes.  So, yes, it looks like either freq_xlating_fir_filter has a bug or 
> you're not using it correctly; I haven't had time to look into it further 
> yet.  I'd recommend you poke around some more in the freq_xlating_fir_filter 
> and make sure your usage is correct.  If you get nowhere, ping the list with 
> the specifics of what you've tried including a code-snippet. - MLD
> {{{
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000301000009
> [Switching to process 75636 thread 0x13603]
> 0x0000000101dc4c5b in volk_free ()
> (gdb) bt
> #0  0x0000000101dc4c5b in volk_free ()
> #1  0x0000000101208591 in gr::filter::kernel::fir_filter_ccc::set_taps ()
> #2  0x00000001012185bf in 
> gr::filter::freq_xlating_fir_filter_ccf_impl::build_composite_fir ()
> #3  0x0000000101218764 in gr::filter::freq_xlating_fir_filter_ccf_impl::work 
> ()
> #4  0x0000000100e5af79 in gr::sync_decimator::general_work ()
> #5  0x0000000100e2db00 in gr::block_executor::run_one_iteration ()
> #6  0x0000000100e6901d in gr::tpb_thread_body::tpb_thread_body ()
> #7  0x0000000100e584be in gr::tpb_container::operator() ()
> #8  0x0000000100e582d4 in 
> gr::thread::thread_body_wrapper<gr::tpb_container>::operator() ()
> #9  0x0000000100df9ae6 in boost::function0<void>::operator() ()
> #10 0x0000000101f8f625 in boost::(anonymous namespace)::thread_proxy ()
> #11 0x00007fff9940c772 in _pthread_start ()
> #12 0x00007fff993f91a1 in thread_start ()
> }}}
> --
> Michael Dickens, OSX Programmer
> Ettus Research Technical Support
> Email: address@hidden
> Web: http://www.ettus.com
> 
> On Aug 4, 2014, at 7:20 PM, Stefan Oltmanns <address@hidden> wrote:
>> thank you very much for testing! The code is in pre-alpha state, and
>> that the About box stops GnuRadio was just a quick-and-dirty hack for
>> testing. Normally About should not do anything else than showing the
>> About Box.
>>
>> Please try again and open the included example.csv with the program.
>> That creates and starts the GnuRadio flowgraph and continuously changes
>> frequency of the hardware and the frequency Xlating filter. You should
>> see four symbolized batteries, with RF level (and counter since last
>> update when there is a signal) written above, frequency and
>> name/description below. In case there is no signal they will be dark
>> grey, otherwise light grey (and in case the program detects a battery
>> signal it can decode they will be green/yellow/red depending on the
>> battery state).
>>
>> _I think I was just able to isolate the problem_:
>>
>> When I only do set_center_freq(frequency_offset) with one Frequency
>> Xlating filter no crashes. You can test that by removing the first or
>> second line of the example.csv (so that two frequency never fit within
>> the 2,4 MHz bandwidth). The other Xlating filters still exists and are
>> active in the flowgraph, but set_center_freq is never called on them.
>> Program is stable then.
>>
>> Just by adding this line:
>>
>> if((freq_len+1)<bat_decoders.size())
>> bat_decoders[freq_len+1]->SetFreqOffset((int)(bat_blocks[freq_pos]->GetFreq())-center_freq);
>>
>> in the for-loop in the very last function (BatMonFrame::OnTimer) will
>> make the program instable again.
>> This does nothing else than setting the frequency of the next Frequency
>> Xlating filter to the same value (if there is one).
>>
>> I don´t see how this can be a bug in my program, I think it has to be a
>> bug in GNURadio (as it is not predictable and caused by doing the same
>> thing on two different instances of the same object in very short time
>> range -> my guess would be a threading problem). Can you confirm that?
>>
>> I tested this on two different systems (Quad-Core Haswell and Dual-Core
>> Ivy Bridge mobile), same result for both.
>>
>> Thank you very much,
> 
>