Home/ Questions/Q 7058683
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T04:08:31+00:00

I’ve run into a problem where the open function never returns when I try

  • 0

I’ve run into a problem where the open function never returns when I try to open a serial port. It doesn’t happen all the time, and the problem disappears for a while if I unplug my USB to serial adapter and plug it back in. My code looks like this:

fileDescriptor = open(bsdPath, O_RDWR | O_NOCTTY);

where bsdPath is /dev/cu.KeySerial1 . I’ve tried adding the O_NONBLOCK option to the open command, but it still hangs.

Of course I’d like to understand why this is happening. My belief is that whatever the problem, with O_NONBLOCK specified, open should return no matter what even if it was unable to open the port. If it’s unable to open the port, fileDescriptor should be -1 and errno should be set (I check for this immediately after the call to open). Of course, this isn’t happening. Is my assumption incorrect? Is there some known reason for open() to never return even with O_NONBLOCK specified when an error is encountered?

Using the latest version of the Prolific PL-2303 driver with a PL-2303 based USB to serial adapter on 10.7.2, I’ve been able to reproduce this problem again today. A few notes:

  • When hung in the open() call, the process is not interruptible using command-. (control-C).
  • Running ps -avx shows a process state code of U for the process. I’m not sure what this code means. It doesn’t appear in man pages for ps found by Googling. There is no listing of process state codes in the man page for ps on my machine. Perhaps it’s specific to the Mac (10.4+?) version of ps?
  • I noted that on the run immediately before the first appearance of this problem, my call to ioctl() to reset the options on the port back to their state before I changed them for use in my program hung. I had to kill the program (via Xcode’s debugger). Immediately after this, on the next launch of the program, open() hung…
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problem is likely in the device driver. You are correct about how O_NONBLOCK should behave, but it is up to the driver to implement that correctly. It would be helpful to know which version OS X and which USB to Serial device is being used.

    Standard procedures would be to make sure the device is plugged directly into the CPU USB ports (not a hub), check cables, and check for updated drivers.

    Also, when open() is blocking, is the process interruptible by control-c?
    If you look at the process with “ps -aux” while its blocked, what does the “STAT” field say?

    • 0