This sounds like a memory corruption error of some sort. Try printing the
values after calling the volk function and see if they have been changed.

On Tue, Jan 23, 2018 at 2:22 AM, Gilad Beeri (ApolloShield) <
[email protected]> wrote:

> Hi,
> I have the following function:
>
> float blk::func(uint16_t *argmax, gr_complex *vector, uint32_t vlen) {
>       cout << "0: " << vector[0] << " (" << abs(vector[0])<< ")"
>         << " 996: " << vector[996] << " (" << abs(vector[996]) << ") "
>         << " 999: " << vector[999] << " (" << abs(vector[999]) << ")" <<
> endl;
>       volk_32fc_index_max_16u(argmax, vector, vlen);
>       const gr_complex max_mag_sample = vector[*argmax];
>       const float max_abs = abs(max_mag_sample);
>       return max_abs;
>     }
>
> It works most of the time. But seldom, I have some input that causes it to
> return argmax which isn't the index of the sample with the biggest
> magnitude (this is reproduced between different executions - for the same
> input vector, given the same conditions, the wrong argmax is returned). Any
> idea what can cause it, or how to debug it?
>
> Some info:
>
>
>    1. GNU Radio 3.7.11.1.
>    2. When I compile with -DCMAKE_BUILD_TYPE=RelWithDbgInfo (or Debug),
>    the issue doesn't happen.
>    3. When I add specific debug prints, the issue doesn't happen, but
>    with some debug prints I'm able to reproduce the problem. See below.
>    4. I have several ways to "solve" ("hide" will be a better word) the
>    issue, for example, moving the buffer allocation of vector to the loop body
>    (a loop calls the above function each iteration) seems to "solve" the
>    issue, but I'm concerned that it only hides a bug that will surface again
>    (and this is a hard bug to catch, because it doesn't crash, just returns
>    wrong results).
>    5. None of the variables I created (buffer, argmax, vlen) are
>    volk-aligned (weren't created using volk_malloc()).
>    6. volk_32fc_index_max_16u() writes 996 to argmax, while 999 is the
>    biggest sample (the debug print below at the least proves that the last
>    sample is bigger than vector[argmax]). If I try passing "vlen - 1"
>    (remove the last, biggest sample), I get argmax 880, which seems like
>    the actual 2nd biggest.
>    7. I'm certain about the issue because I'm able to print the values of
>    the samples. My vector is 1000-sample long (vlen == 1000).
>    8. Most inputs work as expected.
>    9. Oddly enough, even adding "vector[996] = 0" as the first line in
>    the function doesn't help: the function still chooses 996 as argmax (and I
>    verified that the sample is really 0)!
>       1. When setting the last sample to 0 (instead of #996), argmax is
>       chosen to be 880, so it basically seems like "if the last (#999) sample 
> is
>       the biggest, choose 996".
>    10. If I pass vector+1 (start at the 2nd sample) and vlen-1 (until the
>    end), I get the last sample (so correct results because it's the biggest).
>
> cout << "0: " << vector[0] << " (" << abs(vector[0])<< ")"
>         << " 996: " << vector[996] << " (" << abs(vector[996]) << ") "
>         << " 999: " << vector[999] << " (" << abs(vector[999]) << ")" <<
> endl;
> ->
>
> 0: (-0.00345266,-0.00122826) (0.00366463) 996: (0.000987553,0.00248463)
> (0.0026737)  999: (0.0273567,0.00109235) (0.0273785)
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to