Found it:

Created an C++ app that called that function with the same parameter
values as with python for this flow graph. Witch I was able to debug
normally.

In window.cc line 265, with i = ntaps - 1, temp = 1.0000000000000000002
that cause sqrt (0) witch return "-nan" on the next line and screw all
the rest of the calculations.

This only happens when compiled with "CFLAGS=-march=native -O2", if I
don't specify the march it's working correctly. The function is called
on my system with taps=787 and beta = 7.

Regards:
Cor

On Wed, 2017-06-21 at 15:13 +0200, Cor Legemaat wrote:
> Hi:
> 
> > > Sorry for the late replay... The intel pc call filter.firdes.low_pass
with the same values but return 768 proper float values, not like the
<nan>'s on the AMD pc.
> 
> > > > > > > Tried to debug with "nemiver /usr/bin/python2.7 -u
<path>/fm_receiver.py" and the breakpoint at firdes.cc line 100 witch
get triggered and I can read the function parameters but when I try
to step true the function it jumps to the assembly of pthread. If I
put more breakpoints in firdes.cc I get back to the function but cant
read any variables any more. Also tried exporting "export
GR_SCHEDULER=STS" but the same symptoms.
> 
> > Don't know if Ubuntu will trigger the bug it's probably compiled more
generic...
> 
> Regards:
> Cor
> 
> On Wed, 2017-06-07 at 04:26 -0400, Anon Lister wrote:
> > > > > > I have an AMD system with the same chip running Ubuntu 16.xx. I can
probably try to duplicate this weekend, if Cor doesn't get to it,
as another data point. 
> > > > > > On Jun 5, 2017 3:14 PM, "Marcus Müller" <marcus.muel...@ettus.com>
wrote:
> > 
> >   
> >     
> >   
> >   
> >     Hi Cor,
> > 
> >     
> > > >     Excuse the language, but faaaark. Ok, looks like we have a bug
in
> > > >       low_pass. Or in GCC. Or SWIG (which does the python-wrapping
of
> >       the code in firdes.cc). yay.
> >     So, let's narrow this down: on intel and amd64, same number of
> >       taps, right?
> >     Then: If I asked you to use GDB to verify the C++ low_pass
> > > >       function in gr::filter::firdes::low_pass actually returned
the
> > > >       right float values, would you feel that, with a few hints, be
able
> >       to do that?
> >     Best regards,
> >     Marcus
> > 
> >     
> >     
> > 
> >     On 01.06.2017 07:20, Cor Legemaat
> >       wrote:
> > 
> >     
> > 
> > >       Hi:
> > > 
> > > filter.firdes.low_pass get called with:
> > >  * fractional_bw = 0.4
> > >  * trans_width = 0.1
> > >  * mid_transition_band = 0.45
> > >  * interpolation = 24
> > > 
> > > But return: (nan, <788 times nan>)
> > > 
> > > Regards:
> > > Cor
> > > 
> > > On Tue, 2017-05-30 at 00:06 +0200, Marcus Müller wrote:
> > > 
> > > >         Hi Cor,
> > > > 
> > > > >            * When using 1 as "taps" there is output.
> > > > > 
> > > >          Aha!!
> > > > > > > > So, here's the thing: something might be going wrong in the
python
> > > > code that sets up the taps automatically if you don't set them
> > > > explicitly. 
> > > > > > > > Maybe you can figure out where things go wrong; the interesting
part
> > > > (maybe add some `print`s here?) from [1]:
> > > > 
> > > > > > > >         # If we don't have user-provided taps, reduce the
interp and
> > > > > > > >         # decim values by the GCD (if there is one) and then
define
> > > >         # the taps from these new values.
> > > >         if taps is None:
> > > >             interpolation = interpolation // d
> > > >             decimation = decimation // d
> > > >             taps = design_filter(interpolation, decimation,
> > > > fractional_bw)
> > > > 
> > > > and
> > > > 
> > > > 
> > > > def design_filter(interpolation, decimation, fractional_bw):
> > > >     """
> > > > > > > >     Given the interpolation rate, decimation rate and a
fractional
> > > > bandwidth,
> > > >     design a set of taps.
> > > > 
> > > >     Args:
> > > >         interpolation: interpolation factor (integer > 0)
> > > >         decimation: decimation factor (integer > 0)
> > > > > > > >         fractional_bw: fractional bandwidth in (0, 0.5)  0.4
works
> > > > well. (float)
> > > >     Returns:
> > > >         : sequence of numbers
> > > >     """
> > > > 
> > > >     if fractional_bw >= 0.5 or fractional_bw <= 0:
> > > > > > > >         raise ValueError, "Invalid fractional_bandwidth, must
be in
> > > > (0, 0.5)"
> > > > 
> > > >     beta = 7.0
> > > >     halfband = 0.5
> > > >     rate = float(interpolation)/float(decimation)
> > > >     if(rate >= 1.0):
> > > >         trans_width = halfband - fractional_bw
> > > >         mid_transition_band = halfband - trans_width/2.0
> > > >     else:
> > > >         trans_width = rate*(halfband - fractional_bw)
> > > >         mid_transition_band = rate*halfband - trans_width/2.0
> > > > 
> > > > > > > >     taps =
filter.firdes.low_pass(interpolation,                    
> > > > # gain
> > > > > > > >                                  
interpolation,                    
> > > > # Fs
> > > > > > > >                                  
mid_transition_band,              
> > > > # trans mid point
> > > > > > > >                                  
trans_width,                      
> > > > # transition width
> > > >                                   filter.firdes.WIN_KAISER,
> > > > > > > >                                  
beta)                             
> > > > # beta
> > > > 
> > > >     return taps
> > > > 
> > > > 
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > > > > > [1] https://github.com/gnuradio/gnuradio/blob/master/gr-filter/
python
> > > > /filter/rational_resampler.py
> > > > 
> > > > On 29.05.2017 19:01, Cor Legemaat wrote:
> > > > 
> > > > >           Hi:
> > > > > 
> > > > > > > > > >  * The only warning is about the thread priority but that's
on
> > > > > both.
> > > > >  * Type "Complex->Complex (Complex Taps)"
> > > > >  * When using 1 as "taps" there is output.
> > > > > 
> > > > > > > > > > I can open it in Nemiver if I know where to put the break
point...
> > > > > 
> > > > > Regards:
> > > > > Cor
> > > > > 
> > > > > On Mon, 2017-05-29 at 11:36 +0200, Marcus Müller wrote:
> > > > > 
> > > > > >             Hi Cor,
> > > > > > > > > > > > that's kind of surprising¹. My first bet is that your 
> > > > > > > > > > > > AMD
system
> > > > > > is
> > > > > > missing some dependency that the intel system has, so that
> > > > > > something
> > > > > > > > > > > > goes wrong during build. But then again, you shouldn't 
> > > > > > > > > > > > be
seeing
> > > > > > the
> > > > > > > > > > > > rational resampler block at all in that case. Let's head
straight
> > > > > > to
> > > > > > debugging:
> > > > > > > > > > > > * Do you get any warning/console output during the
execution of
> > > > > > that
> > > > > > flow graph?
> > > > > > > > > > > > * Which is the input/output type (float or complex, 
> > > > > > > > > > > > orange
or
> > > > > > blue
> > > > > > connector in GRC, if using that)
> > > > > > > > > > > > * If in GRC: when explicitly using [1,] as "taps", do 
> > > > > > > > > > > > you
get
> > > > > > output?
> > > > > > Best regards,
> > > > > > Marcus
> > > > > > 
> > > > > > ¹ "wat?!"
> > > > > > 
> > > > > > On 29.05.2017 06:35, Cor Legemaat wrote:
> > > > > > 
> > > > > > >               Hi:
> > > > > > > 
> > > > > > > > > > > > > > I have 2 different hardware setup's with 
> > > > > > > > > > > > > > funtoo/gentoo
and
> > > > > > > gnuradio
> > > > > > > > > > > > > > installed. On the Intel system the "Rational 
> > > > > > > > > > > > > > Resampler"
is
> > > > > > > working
> > > > > > > > > > > > > > correctly but on the AMD system there is no output. 
> > > > > > > > > > > > > > This
is on
> > > > > > > a
> > > > > > > flow
> > > > > > > > > > > > > > graph for an basic wide band fm receiver based on 
> > > > > > > > > > > > > > the
USPR
> > > > > > > 10min fm
> > > > > > > receiver tutorial.
> > > > > > > 
> > > > > > > AMD system:
> > > > > > >  * AMD FX(tm)-8150 Eight-Core Processor
> > > > > > > > > > > > > >  * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt 
> > > > > > > > > > > > > > sse sse2
sse3
> > > > > > > sse4_1 sse4_2 sse4a ssse3 xop"
> > > > > > > 
> > > > > > > Intel system:
> > > > > > >  * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz
> > > > > > >  * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3
> > > > > > > sse4_1
> > > > > > > sse4_2
> > > > > > >    ssse3"
> > > > > > > 
> > > > > > > > > > > > > > Tried with different versions of GNURadio and gcc 
> > > > > > > > > > > > > > but the
same
> > > > > > > > > > > > > > symptoms, both systems is compiled with CFLAGS="-
march=native
> > > > > > > -O2
> > > > > > > -pipe". At the moment it is gcc:6.3.0  and net-
> > > > > > > wireless/gnuradio-
> > > > > > > > > > > > > > 3.7.11:0/3.7.11  USE="alsa analog atsc audio 
> > > > > > > > > > > > > > channels
digital
> > > > > > > doc
> > > > > > > dtv
> > > > > > > examples fec filter grc noaa pager performance-counters
> > > > > > > portaudio
> > > > > > > qt4
> > > > > > > > > > > > > > uhd utils vocoder wavelet wxwidgets zeromq -fcd 
> > > > > > > > > > > > > > -jack
-log -oss
> > > > > > > -sdl {-
> > > > > > > test} -trellis" PYTHON_TARGETS="python2_7"
> > > > > > > 
> > > > > > > Where do I start to search?
> > > > > > > 
> > > > > > > Regards:
> > > > > > > Cor
> > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Discuss-gnuradio mailing list
> > > > > > > Discuss-gnuradio@gnu.org
> > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > > > > 
> > > > > >              
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Discuss-gnuradio mailing list
> > > > > > Discuss-gnuradio@gnu.org
> > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > > > 
> > > >          
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > 
> > > >         
> > > > 
> > > >         
> > > >         
> > > > 
> > > >         _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > 
> >     
> > 
> >   
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 
> > Discuss-gnuradio mailing list
> > 
> > Discuss-gnuradio@gnu.org
> > 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to