Hello, I'm using pulseview with a siglent sds1104x-e oscilloscope attacked using the tcp-raw driver. How to reproduce the bug: 1. open pulseview 2. start capture and wait for trigger 3. after capturing the data you're interested in, stop the capture Expected behavior: Capture stops Actual behavior: Pulseview completely hangs until killed. Meanwhile, this is the output on the console (using -l 5 option): sr: [03:06.480079] session: bus: Received SR_DF_ANALOG packet (0 samples). sr: [03:06.480088] siglent-sds: 14000000 of 14000000 block bytes read. sr: [03:06.480096] siglent-sds: Requesting: 0 bytes. sr: [03:06.480104] siglent-sds: Received block: 3563944, 0 bytes. sr: [03:06.480112] session: bus: Received SR_DF_ANALOG packet (0 samples). sr: [03:06.480120] siglent-sds: 14000000 of 14000000 block bytes read. sr: [03:06.480128] siglent-sds: Requesting: 0 bytes. sr: [03:06.480136] siglent-sds: Received block: 3563945, 0 bytes. (this goes on forever)
sr: [03:06.480128] siglent-sds: Requesting: 0 bytes. Must be a bug in the driver, reassigning. My gut feeling tells me that it's probably a matter of a wrong comparison somewhere (e.g. < vs. <=).
Created attachment 718 [details] SDS 1104X-E patch to fix the infinite loop
I've triaged the issue and made a patch to fix it (attached) for my SDS 1104X-E. However, this is slightly hacky, as I don't have full understanding of what has lead to the issue in the first place. Presumably after all, this protocol has worked fine in the past and the issue has possibly come up with a firmware update? I'm a bit too worried that the patch breaks some other Siglent devices, so further investigation would be necessary before taking this patch into production. There seems to be two bugs in the waveform retrieval loop that will get triggered on depending on the waveform length. 1) This occurs only with really small timebases, where the waveform data is less than 363 bytes. If 1st read returns more bytes than the expected sample count (and it will always return 363 bytes), it will just read straight from the buffer. The 1st read however ONLY reads the header, so the waveform data has not yet been read from the socket into the buffer --> buffer overflow and segfault 2) In case of multiple blocks, it calculates the number of bytes it still needs to download to retrieve the whole waveform. However the counter for downloaded bytes includes already the header length and this is not accounted for properly in the section that calculates the number of bytes needed to read, so it just tries to read 0 more bytes. The next step in the loop however does account for the header length, and detects that there are still 363 bytes missing and keeps the loop going.
The patch needs more work, it currently works only for single channel. There seems to be unread data in the socket which causes various issues. This is possibly related to linefeeds at the end of the waveform message.