Summary: | sigrok-cli crashes when the Link Instruments' MSO-19.2 is connected | ||
---|---|---|---|
Product: | sigrok-cli | Reporter: | Peter Mortensen <spamMayGoHere> |
Component: | Other | Assignee: | Nobody <nobody> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | uwe, wsa |
Priority: | Normal | ||
Version: | unreleased development snapshot | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
Peter Mortensen
2018-04-09 22:08:00 CEST
"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. |