| 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-sniffer | Assignee: | Bert Vermeulen <bert> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unreleased development snapshot | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 45 | ||
(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 Fixed in bf25678359 |
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.