<d1b2>
<louis> when called from updating the parameter races against ::Refresh() (conjecture) and starts corrupting memory
<d1b2>
<louis> which for some reason on my system seems to lead to remarkable lockups
<d1b2>
<louis> proposal: we just remove that... decreasing the buffer size will already cull extra samples and I don't see the need for increasing it to delete existing samples
<d1b2>
<louis> otherwise we can add a flag and do the actual clearing in ::Refresh()
<azonenberg>
No. thats a missing lock somewhere
<azonenberg>
clearsweepps needs to wipe stuff properly
<azonenberg>
gimme a few
<azonenberg>
probably the gui thread needs to hold waveformdatamutex exclusively
<d1b2>
<louis> OK
<d1b2>
<louis> Related UX question, I would like / have expected the Trend filter to take buffer size in seconds, not samples
<d1b2>
<louis> since the samples/sec is completely determined by your filter graph update speed, right?
<d1b2>
<louis> you can achieve this effect with Trend -> Window, but that was not immediately apparent to me
<azonenberg>
we can have an option for either
<azonenberg>
PRs welcome
<d1b2>
<louis> 👍
<azonenberg>
i'll look into the race
<azonenberg>
near term workaround, dont change depth w/ triggers live
<d1b2>
<louis> that was not sufficient to prevent the issue all the time in my experience
<_whitenotifier-9>
[scopehal-apps] azonenberg 802674e - Updated to latest scopehal-docs
<_whitenotifier-9>
[scopehal-apps] azonenberg 196f981 - MainWindow: fixed bug where OnFilterReconfigured would call ClearSweeps() without locking the waveform data mutex, potentially racing with background updates of the filter graph
<azonenberg>
@louis: please test
<azonenberg>
so what was happenign is, SetData(nullptr) frees the current data
<azonenberg>
the refresh or rendering thread had already acquired that pointer and was writing to it