discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Oltmanns
Subject: Re: [Discuss-gnuradio] Stable on Linux, many crashes on Windows and OS X
Date: Tue, 05 Aug 2014 01:20:42 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:24.0) Gecko/20100101 Thunderbird/24.0

Hi Michael,
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,
Stefan


Am 04.08.2014 15:16, schrieb Michael Dickens:
> Hi Stefan - OK; well if "make test" worked on OSX for you then the GR install 
> is probably good to go.  No guarantees.  If you uninstall your OO-MacPorts GR 
> install and use gnuradio-devel, then you will should get the same results (if 
> not better).  I'm not sure why you would want an OO-MacPorts GR install 
> unless you wanted to change GR itself.
> 
> After tweaking "build_osx" for my setup, everything builds nicely.  Running 
> "./batmon" I see an empty window and basic menus; nothing else.  I can leave 
> it running (in gdb) for a long time without it crashing.  I don't know what 
> to do with it otherwise.  I have an Ettus B210 hooked up.
> 
> If I select "batmon" -> "About" I see the about box, which when I close 
> crashes the executable.  Looking through the code in main.cpp, 
> BatMonFrame::OnAbout calls BatMonFrame::StopReceiver, which in turn calls 
> "gr_tb->stop" even though gr_tb has not been initialized (I set a breakpoint 
> where it is set, and the code does not get there before this call).  Probably 
> best to check gr_tb before using it, just in case, in all the methods that 
> call it.  Also, I'm not sure why you would stop processing -after- the about 
> box has been closed; maybe beforehand makes more sense?
> 
> If you let me know what else to test, I'll try that too.  Otherwise, without 
> actual functionality the basic GUI seems to "work". - MLD
> --
> Michael Dickens, OSX Programmer
> Ettus Research Technical Support
> Email: address@hidden
> Web: http://www.ettus.com
> 
> On Aug 3, 2014, at 12:00 AM, Stefan Oltmanns <address@hidden> wrote:
>> thank you very much for your help. I´ve attached the program in it´s
>> current state (messy pre-alpha code) to this mail. It´s a GUI
>> application (wxWidgets). On my system it compiles with build_osx (it´s
>> just one line and probably won´t work without editing on other systems).
>> After program is started: File->Open Transmitter Configuration and
>> select example.csv, GNURadio is started and in a timer loop frequency
>> will be changed for source and Frequency Xlating filter. On Linux I
>> tested it for about two hours and no crash.
>> Of course there could also be something wrong with my program and on
>> Linux it just doesn´t cause any problem.
>>
>> It uses OsmoSDR source, so other devices should work as well. Note that
>> sample rate is currently hardcoded in the source (2,4 MHz).
>>
>> I did run make test on OS X and it completed with 100% pass.
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]