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