CanConFactory::create() returns nullptr for a type the platform does not
support, and loadConnections() handed that straight to the model, which
appends it to the connection list unguarded. Every later iteration over that
list then dereferences it.
Reachable by carrying a settings file holding a gs_usb connection from
Windows to another platform, and by any saved type id the factory does not
recognise.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XZnuZJ7zc3e8hk6C8bGDZN
candleLight, CANable, CANnectivity and cantact adapters speak gs_usb. On
Linux and macOS the kernel driver exposes them as SocketCAN interfaces, so
SavvyCAN already reached them through Qt SerialBus. Windows has no such
driver, which left those adapters unusable there.
Add a GSUSBConnection that talks to the hardware directly over WinUSB:
- one connection per physical device, one SavvyCAN bus per CAN channel
- CAN FD including BRS, plus RTR, extended IDs and error frames
- known good bit timings for 16/48/80/160/170 MHz device clocks, with a
generic solver for clocks the tables do not cover
- hardware timestamps, unwrapped across the 32 bit rollover and anchored
to the host clock so they line up with the rest of SavvyCAN
gs_usb multiplexes every channel over a single USB bulk IN endpoint, so a
single reader thread drains it and hands frames to the connection thread in
batches, coalescing the wakeups. That keeps one producer on the lock free
queue, which the tx echo path already writes to.
Device scans skip adapters that a live connection holds. candle_dev_open()
shares the file handle and queues read URBs immediately, so probing a device
in use would consume frames the open connection is waiting for.
connections/candle_api is an unmodified copy of the candle Windows API, LGPL
3.0 rather than MIT and only compiled into Windows builds. See its README for
provenance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XZnuZJ7zc3e8hk6C8bGDZN
...to graphing window and signal viewer so complex systems with message
name duplication (eg "Status") works well. DBCHandler class has a new
function to find a msg by fully qualified node name...Utility class defines
the qualified name seperator, right now it is :: and is used thusly
filenameNoExtension::nodeName for display in the node dropdown (because
nodes can be common between dbc files). To get the message from the
system you use the findMessage function in dbchandler and pass the
msgName and the fully qualified node name. This is about as unique as we
can get, second only to message ID.
Added node comboBox to graph signal editor for easier data filtering
(took the same implementation that was in signal viewer, and tuned up
both of them)
This is useful if you have a 1920x1080 monitor or smaller resolution
but you want to capture 64 byte payloads. The default is 8 bytes but
usually 16 bytes is fine.
