Hi Eugene,I believe there is this bug in other places (including other places in control_loop) too. Basically any time that an input float is used to compute an error which then ends up indexing some array (as could happen in a closed loop that indexes into filterbank), if the input is NaN, then NaN will propagate through the float calculations and give an absurd value when cast to int to obtain the index. Some day someone will go and fix all these (though the best fix is not obvious, since performance is also a concern).
Are you sure that in the code snippet you've shared replacing int by uint8_t fixes the problem? I haven't looked at the standard, but I imagine that casting a NaN float to uint8_t is UB. Maybe this doesn't cause a segfault because even though there is UB, in this particular build the index ends up having some value between 0 and 255, which is fine to index into tanh_lut_table without causing segfault (but the result would be wrong/unpredictable!), whereas with an int index the int can have any large (positive or negative) value that causes a segfault when indexing.
Best, Daniel. On 06/06/2024 20:33, Eugene Grayver wrote:
Hi,Found a minor (but annoying to track down!) bug in include/gnuradio/blocks/control_loop.h.If the input is NaN, then neither of the if statements evaluates to true, and the program segfaults.My company policy requires jumping through some hoops to make a direct github contribution.I suggest a patch:instead of 'int index', make it 'uint8_t index' and that will solve the segfault.static inline float tanhf_lut(float x) { if (x > 2) return 1; else if (x <= -2) return -1; else { int index = 128 + 64 * x; return tanh_lut_table[index]; } } Eugene.
OpenPGP_signature.asc
Description: OpenPGP digital signature