You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calling digital::fll_band_edge_cc::set_samples_per_symbol() in a multi-threaded environment with the flowgraph running may cause a segmentation violation.
set_samples_per_symbol() implementation calls fll_band_edge_cc::design_filter() which may change the size of the d_filter_lower and d_filter_upper vectors which are used in the fll_band_edge_cc::work() method. In a threaded environment it is possible for work() to be running at the same time as a filter update and this may allow previously freed memory to be accessed if the filter vector gets smaller.
Suggest adding gr::thread::scoped_lock(d_mutex) to the fll_band_edge_cc block to prevent this happening.
System Information
OS: Ubuntu 20.04 LTS
GR build from sources on "maint-3.10" branch
Based on code inspection this bug appears to affect multiple releases
GNU Radio Version
3.10 (maint-3.10)
Specific Version
3.10.5.0-1-g480f600c
Steps to Reproduce the Problem
Bug was discovered after much head-scratching by rebuilding and running gnuradio and op25 with an address sanitizer.
While I don't have a specific test-case available, you should be able to reproduce the problem by running a flowgraph at the same time as making calls to set_samples_per_symbol() that increase then decrease the SPS value.
Relevant log output
No response
The text was updated successfully, but these errors were encountered:
add a lock to protect the d_filter_lower and d_filter_upper vectors from concurrent access. The proposed code change is to add gr:::scoped_lock(d_mutex) within the fll_band_edge_cc block to ensure that only one thread can access the filter vectors at a time. This will prevent the race condition and potential segmentation violation.
@geekyraghav13 well, you proposed what seems to be a reasonable change, so that's why we're encouraging you to send us your proposed patch in the shape of a pull request (PR). But it's alright if you can't fix this bug right now, then someone else has to do it later.
What happened?
Calling digital::fll_band_edge_cc::set_samples_per_symbol() in a multi-threaded environment with the flowgraph running may cause a segmentation violation.
set_samples_per_symbol() implementation calls fll_band_edge_cc::design_filter() which may change the size of the d_filter_lower and d_filter_upper vectors which are used in the fll_band_edge_cc::work() method. In a threaded environment it is possible for work() to be running at the same time as a filter update and this may allow previously freed memory to be accessed if the filter vector gets smaller.
Suggest adding gr::thread::scoped_lock(d_mutex) to the fll_band_edge_cc block to prevent this happening.
System Information
OS: Ubuntu 20.04 LTS
GR build from sources on "maint-3.10" branch
Based on code inspection this bug appears to affect multiple releases
GNU Radio Version
3.10 (maint-3.10)
Specific Version
3.10.5.0-1-g480f600c
Steps to Reproduce the Problem
Bug was discovered after much head-scratching by rebuilding and running gnuradio and op25 with an address sanitizer.
While I don't have a specific test-case available, you should be able to reproduce the problem by running a flowgraph at the same time as making calls to set_samples_per_symbol() that increase then decrease the SPS value.
Relevant log output
No response
The text was updated successfully, but these errors were encountered: