Re: [Discuss-gnuradio] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

[Gilad Beeri (ApolloShield)]

I also suspect a memory corruption but couldn't pinpoint its source.

Per your suggestion, I copied the same cout statement to the end of the function (before the return call), the output is exactly the same (so the #0, #996, and #999 samples weren't changed) and argmax is still wrongly 996.

On Tue, Jan 23, 2018 at 12:45 PM Jeff Long <address@hidden> wrote:

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) <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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