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

[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,