I’m running the Linux ubuntu trusty builds:
2.0.15 Works fine even when connected to my pixhawk with USB cable. But when I connect with 3DR radio s APM Planner will cash at random times.
I’ve tried to narrow the issue down:
2.0.11 -> Stable on Radio Link
2.0.12 -> Stable on Radio Link
2.0.13 -> Stable on Radio Link
2.0.14 -> Stable on Radio Link
2.0.15rc1 -> Stable on Radio Link
2.0.15rc2 -> Cannot find download link of compiled version. (Attempting to compile my own right now)[color=#FF0000]*Edit-> Crashes after radio link[/color]
2.0.15rc3 and above -> All crash at random times after radio link is established.
Wondering if there is a commit some place between rc1 and [color=#FF0000] rc2[/color] that is causing the issue.
Anyone else experience this?
I’ve backed up the commits right to the point QT 5 was implemented with the same results.
I suspect that something is different between how QT4 and 5 handles serial ports… Still digging…
In Qt4 we where using a backported version of Qt5 SerialPort implementation. There have been some changes to the serial port implementation since that (and it has caused some issue with OSX). The version in Qt5.2.1 seems to be working OK with me. (OSX 10.10)
You can try some other options in that serial link.cc to use a separate threading model or not. YMMV. The #define options are mutually exclusive.
Thanks for pointing towards some things to try Bill. I tried all three versions of threading, all with the same random crashing after serial link connection. I was also using Qt5.2.1
I googled my stack trace to try and pinpoint the issue and found that there is a known issue with libxcb.
As quoted from Qt forums (Uli Schlachter):
(There was a race in libxcb where it first made sure that libxcb isn’t writing to the socket, then made sure that Xlib isn’t using the socket. By the time the following check was done (which involved acquiring a mutex and thus sleeping), another thread was already using the socket again from within libxcb.)
Also seems that this bug doesn’t happen on all hardware.
The most common work-around apparently is to use Qt 5.3.
I have compiled with Qt5.3 and no more crashing. Yet… (however there is other UI issues that need fixing with 5.3)
I will update this thread if there still is an issue.