azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<_whitenotifier-9> [scopehal-docs] azonenberg pushed 2 commits to master [+6/-0/±6] https://github.com/glscopeclient/scopehal-docs/compare/ad8863453e59...91f201e70b65
<_whitenotifier-9> [scopehal-docs] azonenberg 04dd213 - Added "history" section to ngscopeclient manual
<_whitenotifier-9> [scopehal-docs] azonenberg 91f201e - Initial work on ngscopeclient filter graph editor docs
<d1b2> <louis> 😦
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 250 seconds]
Degi_ is now known as Degi
<azonenberg> @louis: i think it's borked
<d1b2> <louis> I am getting crashes inside WaveformArea rendering code when adjusting the buffer size on a Trend filter
<azonenberg> innnteresting
<azonenberg> File a ticket and i'll look into it shortly
<azonenberg> give as much detail as you can
<d1b2> <louis> Wtf
<azonenberg> ?
<d1b2> <louis> Ngscope crashed, wouldn't quit, hung as a zombie
<azonenberg> Huh
<azonenberg> havent had that happen. i've had it lock up, but i could still ^C it etc
<d1b2> <louis> Then I straced it and the laptop turned the screen completely off and would not respond to anything but hard shutdown
<d1b2> <louis> Now it's stuck on the bios screen...
<azonenberg> This may not be my code at fault :p
<azonenberg> sounds more like an inconveniently timed hardware issue
<azonenberg> (in the gpu)
<d1b2> <louis> OK, tracked it down
<d1b2> <louis> cpp void TrendFilter::ClearSweeps() { SetData(nullptr, 0); }
<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
<d1b2> <louis> which is somewhat perplexing
<azonenberg> rendering thread race maybe? i'll investigate
<azonenberg> ok so i think i see what's going on
<azonenberg> the clear sweeps button on the toolbar is interlocked with the waveform data mutex
<azonenberg> but i guess its being called from other spots where it isn't
<azonenberg> @louis: do you have a backtrace from where ClearSweeps is being called from during the race?
<azonenberg> ah ok its in OnFilterReconfigured
<_whitenotifier-9> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/glscopeclient/scopehal-apps/compare/d5ad818ac38f...196f9813cfc4
<_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
<azonenberg> so you got a GPU side use-after-free
<azonenberg> which ended poorly
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
balrog has quit [Quit: Bye]
balrog has joined #scopehal
veegee has joined #scopehal