Ocasional PICO_INVALID_HANDLE during detection of ps6000 scopes

[alexxcons]

...
-- Staring flowgraph --
ERROR: No ps6000 device found
ERROR: Exception in /home/bel/schwinn/lnx/git/gr-digitizers/lib/digitizer_block_impl.cc:544: initialize failed. ErrorCode: Ps6000:12
RTDeviceClass::specificInit finished!
NOTICE: timebase cannot be obtained: PICO_INVALID_HANDLE - There is no device with the handle value passed.
NOTICE:     estimated timebase will be used...
...

Observed on fel0049

The bug is reproducable, until pico6000Con/ps6000Con is called once. After that, things work fine again:

-- Staring flowgraph --
INFO: Searching for scope with serial: 'EZ506/056'
INFO: ... found scope with serial: 'EZ506/056'
INFO: Serials match, scope 'EZ506/056' found.
INFO: Triggering enabled for picoscope: 'EZ506/056' Trigger source: 'AUX' threshold: '0.7' direction: '0'.

So that native picotec application does some magic which we currently dont do .. to be investigated.

The ps6000Con source code can be found here: https://gitlab.com/al.schwinn/picodrivertest or can be downloaded somewhere on the picotec website

[alexxcons]

The ps6000Con application does memset(&(allUnits[devCount]),0,sizeof (UNIT)); on the deviceHandle before passing it to ps6000OpenUnit (which in theory should fill that handle, no matter what was inside before).

Currently testing if that does the trick. (I cannot reproduce the bug just like that, so I will run the fesa class for some weeks and see if the bug occurs again)

Edit: Nope, that did not do the trick. It just happened again

[alexxcons]

I just placed a std::cout in front of the ps6000OpenUnit loop during debugging which resolved the problem for that attempt (wtf???)

Here my debugging branch:
https://github.com/fair-acc/gr-digitizers/blob/%23103_ps6000_ocassional_PICO_INVALID_HABLE/lib/picoscope_6000_impl.cc#L445

Suppose that was rather luck, and ha no real relevance.

[RalphSteinhagen]

... such things/observations often indicate data race and other potential threading issues.

[alexxcons]

... such things/observations often indicate data race and other potential threading issues.

Hmm, the used variables all have local scope, and fel0049 only runs a single ps6000 (There is as well a boost::mutex::scoped_lock used to protect from concurrent access, though that is only relevant for dal006 which runs two ps6000 in parallel)