Fixes double open() call on unix #670
Conversation
|
I'm encountering a problem on OS X that might be related to this. When I open() my device, the data comes through just fine. But if I close() it, then open() it again, no data comes through anymore. I have to unplug it, and plug it back in again in order to open() and receive data again. The strange thing is that open() doesn't complain when this is happening, just no data comes through. Update: Finally got a chance to try this, and it fixed the problem. Thanks! |
|
I'm having the exact same problem as shoerob, managed to find it here through search but there doesn't seem to be an open issue. Is this merge really a fix for it? Seems unrelated... but hey, whatever works! How long until this is accepted? |
|
@JonathonAshworth have you not found any open issues about this? I'll run some tests in the next day or two. Should be able to work this into the next release, I can clearly see there's a problem, but I need to put it through its paces and reproduce @shoerob's issue. |
|
I am experiencing a similar issue to @shoerob but this fork did not solve it for me. |
|
Can you give me some code and more information so I can reproduce it? On Wed, Mar 2, 2016, 6:09 PM Andreas Limberopoulos [email protected]
|
|
The relevant code is quite chunky and we're having trouble narrowing down the problem. I've put it in a gist, but I'm going to try and come up with a minimum representation of the problem now so you've got something a bit cleaner to work with! https://gist.github.com/JonathonAshworth/a099183982a8c40747ab Essentially, our code opens each serial port on the computer in turn, sends a test packet to verify that the device responds to the MTK format, then requests firmware information from the device to verify that it's a valid device that was bought from our company. Then it closes the port. This happens for every valid serial port on the computer, generating an array of "valid ports" (i.e ports which represent one of our devices). Then those valid ports are opened a second time so data can be downloaded off them. On the second open, a test packet is once again sent, then a packet requesting the memory status of the device is sent, followed by downloading the actual memory off the device. The problem appears to be with the open-close-open process, and happens only on OSX. If we do not check the validity of a device first, then it downloads just fine, but if the device has been opened and closed previously, then it will be successfully reopened, but will fail later on. Half the time it fails to respond to the test packet, and half the time it successfully responds to the test packet, then fails to respond to the memory status request. The curious part to me at least is that it's sometimes successfully responding to the test packet before failing. It seems as if the device is being randomly closed or randomly failing. |
|
https://gist.github.com/JonathonAshworth/ecafc8a2df376a4063e8 Alright, this is the simplest test I could come up with that is failing. The device constantly outputs a stream of realtime gps data, so the test just opens the device for 5 seconds, logging it's output to console, closes it, then re-opens it for another 5 seconds. This acts as you'd expect on both Ubuntu and Windows, but on Mac, it only ever outputs the very first time the device is opened after plugging it in. The second time it's opened nothing prints, and on subsequent runs it doesn't print either time, until the device is unplugged and plugged in again. My workmate just installed this fork and is reporting that it's working as expected. So it appears this is (somehow) a fix for the issue. |
|
@JonathonAshworth is your device a physical serial device, or it has
another interface (like usb) and just emulates a serial port?
This issue you have may be related to how the driver is reacting to the
"leaked" handle. I had exactly the same issue you're having, but with
Windows. A software in Labview was not properly closing a handle to our
device before exiting, and we were not able to read from it again before
unplugging and plugging it back.
We have an USB device that emulates a serial port for analog signal
acquisition, and we react to the "virtual RTS" signal. In linux, the USB
CDC driver will set this to 1 when it has one or more open fds to the
device, and then back to 0 when all are closed. In this case, it was on
even after closing, what made me look into this.
May be the case either the OS driver is having problems with this left-open
handle, or even your device, with signals like RTS or DTR.
|
| @@ -131,6 +131,9 @@ void EIO_Open(uv_work_t* req) { | |||
| OpenBaton* data = static_cast<OpenBaton*>(req->data); | |||
|
|
|||
| int flags = (O_RDWR | O_NOCTTY | O_NONBLOCK | O_CLOEXEC | O_SYNC); | |||
| if(data->hupcl == false) { | |||
There was a problem hiding this comment.
This is a good patch and I'll incorporate it into my fork but this block should be removed, not moved. HUPCL is not an fcntl flag; it's a tty control flag and has nothing to do with open(2). On Linux x86_64 HUPCL happens to have the same value as O_APPEND so is benign but on other platforms this code might change the intended open behavior.
There was a problem hiding this comment.
Actually it should be moved within the setup() function to be something like this. (Cherry-pick that if desired.)
- includes #670 from @gfcittolin - includes patch from @pabigot moving when we apply HUPCL - Close the fd if we have any errors during setup - Properly receive errors when setting a custom baud rate on OS X
- includes #670 from @gfcittolin - includes patch from @pabigot moving when we apply HUPCL - Close the fd if we have any errors during setup - Properly receive errors when setting a custom baud rate on OS X
|
I've incorporated this and a few more fixes into #728 Thank you! |
Fixes a double call to open() on unix, that leaks a file descriptor and keeps the underlying device open, as discussed on #661