That's mightily interesting! I feel like we should be doing
bug reports, but I'm not sure where.
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.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio