Details
-
Bug
-
Resolution: Done
-
P4: Low
-
5.4.0
-
None
-
This was only tested on Linux Mint, kernel 3.13.0-24-generic, 32 bits machine. I don't know if it's a general issue.
Description
I wrote a complete GUI program around QserialPort days before I got the device I'm supposed to communicate with into my hands. To my surprise, it failed pretty much consistently in just one part.
After isolating the issue in another project, and replacing the send button (the original trigger of the entire process) with a timer (easiest idea I had to remove the GUI), I managed to reproduce it with a few lines of code.
The external device takes “AE” as a command, and will echo “AE” back. In this minimal example, the program is sending an “AE” each 2 seconds, and should get a reply in a real short time (tested it with no timeout, it simply hangs, but I'm sure the device is sending the reply, oscilloscope proved).
But today, it will work fine the first cycle and second cycle... but after the serialPort.close at line 39, the next cycle will open the port... send the “AE”, but will miss the reply event (no signal generated)... after the timeout closes the port (line 45), the next time succeeds, then the fifth fails, the sixth will work fine again, and so on every other time
On the screen the program will output:
start 1
success 2
"AE"
start 2
success 2
"AE"
QSocketNotifier: Invalid socket specified
start 3
timeout 0
start 4
success 2
"AE"
QSocketNotifier: Invalid socket specified
start 5
timeout 0
start 6
success 2
"AE"
If I make the program not to close the port (remove line 39) then it won't fail in ages. Also, if I leave the serialPort.close() at line 39, but remove the read on line 38, it will continue to work forever.
The QSocketNotifier: Invalid socket specified
gets printed after function getHandshake exits, and if I go step by step through the stack after it exits, it corresponds to a readyRead call.
A guy in the IRC gladly offered first aid, and suggested using QT_FATAL_WARNINGS=1 for debugging purposses. This time the debugger will generate:
The inferior stopped because it received a signal from the Operating System. Signal name : SIGABRT Signal meaning : Aborted
Just when it prints the “QsocketNotifier: Invalid socket specified” information.
Attached you'll find the minimal "working" example source code, and the stack trace after the SIGABRT.