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
There are a TON of explorations I did here, many may be unnecessary, but this is a stake in the ground.
The main issue was the strange queue logic in canconmanager::sendFrame which puts the tx data in the rx
queue so it will show up in the displayed data. It caused SIGABRT and SIGSEG to show up everywhere.
It is NOT fixed yet, but TX works over the wire you just can't see it in the tableview.
I thought at first it was only when overwrite data was active, so I put in a a pile of changes to keep
frames and filtered frames as two seperate copies of data where frames was always complete and filtered
was only what was seen in the mainwindow. It made it so the graphing window would work with overwrite
data active which is an improvement. I wouldn't roll these changes back. Because of these changes I
had to update the frame sorting code adjust the refresh function in canframemode.cpp
I also thought it was related to UI updates, but its not, that's been confirmed.
I put a mutex around the custom sender tick timer so that the 1ms timer wouldn't re-enter its callback.
This didn't fix the crash, but it sure seems to make a lot of sense, and the way I did it no elasped
time is lost for tracking purposes, and in reality theres no way 1ms was consistent anyway.
I put a mutex around the shrinking of frames and filteredframes to make sure we weren't deleting at
the same time as accessing, but honestly we acccess those lists in many places without semaphores so
that probably did nothing.
Fixed a bug in FrameSenderWindow:DoModifiers that was improperly parsing and sometimes crashing when
looking for the ~ operator before a symbol.
Also added some minor work to keep row expansion functioning when changing filters or sorting. Need
to make some tweaks so it stops trying so hard when overwrite is not active
Theres also code in main.c taht makes debugging output super verbose.
Committing now to start cleanup
all. More development needed but this is a start. Also added ability
to set serial speed and bus speed in the device setup which may be
useful for other connection devices too.
Also switched from Sphinx generated HTML to GitHub markup help files.
This improves compatibility and will allow the help files to more easily be viewed on github as well.
These frames will show up in the main frame list and can be operated
on as if they came into the program. It is likely that only the
playback window will work for this special use. Other sending windows
are to follow.
* improves window handling a lot
(on Linux GNOME 3 at least: quickly resizing windows left/right, not forced in foreground anymore etc.)
setWindowFlags() inserted in all *window.cpp files except mainwindow
* some whitespace at EOL trimmed
