On Windows 10 (64-bit), both sigrok-cli and PulveView crash when the Link Instruments' MSO-19.2 is connected. MSO-19.2 info: http://www.linkinstruments.com/mso19.htm sigrok-cli crashes when using these parameters: --scan --scan -d gwinstek-gds-800 --scan -d hameg-hmo --scan -d hp-3457a --scan -d hpib-pps --scan -d lecroy-xstream Those 5 drivers all call sr_scpi_scan(). (Note that the folder for hpib-pps is inconstently named, "scpi-pps", not the same as the driver name, as the 4 others.) A total of 10 drivers call sr_scpi_scan(). Of the 5 that do not crash sigrok-cli, one, "hp-3478a", is not exposed (and thus can not be tested). These 4 do not crash sigrok-cli: rigol-ds rohde-schwarz-sme-0x siglent-sds yokogawa-dlm PulveView crashes at startup. This crash happens both for the current nightly and some end-of-2017-12 version. MSO-19.2 and its associated software works fine with its current USB drivers (on Windows 10, up to date with Windows Update). MSO-19.2 appears as a COM port in Device Manager, "MSO-19 (COM19)", implemented with a Silicon Labs chip CP210x. Using a serial port sniffer, it is observed that only an open and a close is performed on COM19 (presumably two system calls); nothing is send to (by sigrok-cli) or received from COM19 (by MSO-19) (in contrast to when the MSO-19's associated software is used, both a lot of system calls (like setting the baud rate) and data to and from COM19). This crash has only been observed on Windows so far. This crash on Windows occurs ONLY when the MSO-19.2 connected, whether it is the only device or when other COM ports are presents (several Arduino Unos). On Linux sigrok-cli does not crash for any of the 4 combinations. Backtrace when (using nightly of sigrok-cli 2018-04-04): kernel32.dll!75ca1190() ntdll.dll!773de89c() KernelBase.dll!76bac43a() msvcrt.dll!77067250() sigrok-cli.exe!0041f047() Line 153 of "src/scpi/scpi.c" starts at address 0x41f047 <sr_scpi_scan+183> sigrok-cli.exe!0043f752() Line 92 of "src/hardware/gwinstek-gds-800/api.c" starts at address 0x43f752 <scan+34> sigrok-cli.exe!0040e288() Line 535 of "src/hwdriver.c" starts at address 0x40e288 <sr_driver_scan+296> sigrok-cli.exe!0040d44e() Line 402 of "src/hwdriver.c" starts at address 0x40d444 <sr_driver_init+20> sigrok-cli.exe!004c5c09() Line 182 of "log.c" starts at address 0x4c5c09 <srd_log+41> sigrok-cli.exe!0040209a() Line 268 of "show.c" starts at address 0x402095 <show_dev_list+5> sigrok-cli.exe!00581a12() Line 253 of "main.c" starts at address 0x581a0d <main+589> sigrok-cli.exe!004013e2() <__tmainCRTStartup+626> kernel32.dll!75ca8654() ntdll.dll!773d4a77() ntdll.dll!773d4a47() The reason for the crash may or may not be a bug in Silicon Labs driver.
"Backtrace when" → "Backtrace when sigrok-cli crashes"
The backtrace is for driver "gwinstek-gds-800" (either explicit or using "--scan" alone).
For the crash on Windows: What is called in the run-time library (msvcrt.dll) from the function "sr_scpi_scan" (that is in "/libsigrok/src/scpi/scpi.c")? sr_scpi_scan_resource()? Is some inlining by the compiler going on so the last function before the library call in not really sr_scpi_scan()?
Could \libsigrok\src\hardware\link-mso19\api.c in any way be involved? It is not in the list of drivers, but what about fall-back to serial, etc.? It appears some development was done in 2012, but perhaps there are some residual bugs in \link-mso19\api.c, e.g. scanning the USB devices?
Could it be snprintf()? From <https://stackoverflow.com/questions/7706936/is-snprintf-always-null-terminating/7707054#7707054>: "Be wary of the Microsoft version of vsnprintf(). It definitely behaves differently from the standard C version when there is not enough space in the buffer (it returns -1 where the standard function returns the required length)."
A workaround for this problem (so PulveView can be used) is to specify the "-D" command-line parameter (e.g. adding " -D" to the "Target" field of the shortcut on Windows). "-D": -D, --no-scan Don't auto-scan for devices, use -d spec only
Please retry with the current nightly installers, there's a good chance that this has been fixed via bug #1031 in libserialport.
Today I tested some PulseView nightlies (some were release and some were debug versions) with MSO-19 connected: PulseView crashed at startup: 2017-12-24 (release?) 2018-04-04 (release?) 2018-04-12 (release?) 2018-04-17 (release?) 2018-04-19 (debug?) 2018-04-22 (debug?) PulseView did ***not*** crash: 2019-03-01 (release?) 2019-03-20 (release?) 2019-04-16 (debug?) 2019-07-16 (both debug and release) When the MSO-19 was not connected, none of these versions crashed at startup (as expected). Thus, it seems this problem has been fixed.
Marking fixed as reported.