For a long time, I’ve been seeing crashes in MP when I choose parameters to plot by clicking in the LogBrowser table rather than using the parameter tree on the right of the table. I get the error when I filter parameters by clicking in the column header as well.
I saw this error message today by running it out of VisualStudio in debug mode:
Managed Debugging Assistant ‘ContextSwitchDeadlock’ : ‘The CLR has been unable to transition from COM context 0x4c04dbe0 to COM context 0x4c04dab8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.’
The log file I’m looking at today is 160 MB. But, I’ve seen the problem with smaller logs in the past as well.
In the debugger, I can continue after the error and the view updates correctly. So it may be just that the search work just needs to be moved to a non-GUI thread.
I did try the most recent version of APM2 as well, but it can t read log files from Arducopter 3.6dev (master). It also crashes for large log files on Windows. It doesn’t crash on Linux.
I have .NET 4.6.2 installed. I’m compiling it with no changes with a direct checkout from github. The version is: 1.3.49.1 build 1.1.6425.27314. I’ve had trouble in the past with the release and beta versions as well. Could it be unique to Windows 8.1?
Like I mentioned I can run it in debug mode out of Visual Studio 2017 and can continue after the error and it seems to work fine. It looks like there is a lockup detection that’s getting triggered.
I can select parameters in the checkbox tree without any troubles, but if I click on the header of the table to filter data types or click on row of the table, I’ll get the failure for the larger file. I used to get the error for smaller files, but I completed deleted my old version of MissionPlanner and used the newly compiled one and got more reliable behavior.
could you try compiling your copy, and then creating the problem, then attaching the debugger? you should be able to get a stack trace while its in its hung state.
Where is the MissionPlanner.log file saved? I see some old ones in the distribution, but no current ones. I also noticed that when I filter a column, Windows immediately says that the GUI is not responding, but may not close it out. If I click around the table while the application is not responding, I get the white overlay on the application and Windows will close it out.
Can the long running operation be put in a non-GUI thread to prevent the temporary GUI lockup?
