Bug 83

Summary: On the second run, OLS sampling locks up without pushing any samples to PulseView
Product: libsigrok Reporter: Joel Holdsworth <joel>
Component: Driver: openbench-logic-snifferAssignee: Bert Vermeulen <bert>
Severity: normal    
Priority: Normal    
Version: unreleased development snapshot   
Target Milestone: ---   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 45    

Description Joel Holdsworth 2013-03-25 10:34:53 CET
1. Run pulseview (with the log-level patch):
    $ pulseview -l4
2. Connect to the OLS
3. Run a single session to the end. The samples should appear correctly.
4. Run a second session. No samples are displayed, and the uncompleted sampling session locks up, without sending SR_DF_END. The sampling thread is stuck in sr_sampling_run.
5. Click close. SR_DF_END is sent, but the sampling thread is still stuck in sr_sampling_run. PulseView joins to this thread, which prevents it from closing.
Comment 1 Joel Holdsworth 2013-03-25 10:35:39 CET
(09:29:19) jhol: what's the general problem?
(09:30:01) biot: we initialize devc, every driver's (unique) device-specific context, when the device is discovered at scan time.
(09:30:18) biot: devc contains things like the usb/serial transport, so that's correct
(09:31:14) biot: b ut it also contains things like the # of samples received, and various other things like that which are _acquisition_ specific, and as such should be reset before every acquisition
(09:31:47) biot: in the case of the OLS, that's the culprit -- the sample counter never gets reset
(09:31:52) biot: hilarity ensues
(09:32:45) biot: to make matters worse, we never really distinguish between a reset after scan and a reset before acq, as it's never been necessary for the cli
(09:33:14) biot: we usually g_try_malloc0() the devc, thus making it all 0
(09:33:48) biot: so it'll require a bit of thought for every driver, not just a big copy-paste operation
Comment 2 Bert Vermeulen 2013-04-15 18:47:44 CEST
Fixed in bf25678359