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 <[email protected]> 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) <
> [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
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to