Closed collin80 closed 8 years ago
I've found that I actually get crashes when sending frames. This will happen even in debugging builds. At least, sending frames seems to make the problem easier to cause. There is a crash when reading the count for filtered frames. It seems like this is caused by regenerating the filtered list so all code that can cause a regeneration to occur is suspect.
Hi Collin, what I currently do to avoid crashes is to restart the computer completely between each capture session. I've done multi-hour captures this way without problems (700.000 frames).
I use a 2007 MacBook running OS 10.7.5 when capturing. The USB connectors are getting a little flaky making it hard to initially connect. Since SavvyCAN doesn't like glitching USB I always check for the ports existence in the /dev directory before running SavvyCAN. Once connected I haven't been having problems recently. It is possible to have reliable USB serial comm. I wrote a home Alarm serial App over 15 years ago using Objective C and this serial API: // AMSerialPort.h // // Created by Andreas on 2002-04-24. // Copyright (c) 2001-2011 Andreas Mayer. All rights reserved.
I tweaked the C code so that glitches and disconnects never cause crashes. This code does system calls to release the port and start over with the same port in midstream without crashing. The mac can crash and restart with this app starting up and seamlessly reconnecting. I think a few months ago I used the App to re-enable the GVRET port that SavvyCAM couldn't find and mysteriously connect in parallel to GVRET with SavvyCAM. The code still works compiled with the latest OS thanks to Andreas keeping the API up to date. Not sure if your stuck with QT's serial, but I think you can do better.
Various fixes since the time this issue was started have drastically increased stability. It seems to usually do just fine and capture indefinitely now. (V152)
However, recent testing has allowed me to crash it still. If the GVRET hardware glitches it can lock up SavvyCAN. I did this by logging too close to a running inverter that was taken apart. This is pretty much the height of EMI. I should investigate how to handle the GVRET hardware getting taken out, perhaps very suddenly and powerfully. The problem seems to be when the hardware is unexpectedly gone in the middle of communicating with the PC.
Problem 1 from this issue is now fixed in V156.
It seems like there are still some random crashes while capturing. They never seem to happen in debugging builds (naturally) or when a debugger is attached to a release build. But, sometimes the program will crash while capturing with a release build.
It would be good to get reports if anyone knows what could cause this. It seems to very rarely happen now but any crash is one crash too much.