-[NSFileHandle readInBackgroundAndNotify] opens the file again

  • I'm using NSFileHandle in an ARC app on OS X Lion to read from a serial port.

    Everything works fine 'till I go to close the port. I open the port with POSIX calls, set up some stuff, then instantiate an NSFileHandle with the file descriptor I got from open().

    Then I call -readInBackgroundAndNotify, and a second file descriptor gets opened (I see this by using lsof).

    That FD gets closed the moment some data comes in and a notification gets posted, but I just go right back and call -readInBackgroundAndNotify again to get the next data.

    The problem is when I go to close the port. I still have a pending -readInBackgroundAndNotify, and so the port is opened twice. When I call -closeFile on the NSFileHandle, it closes the FD I initially opened, but leaves the second FD open.

    I tried setting the NSFileHandle reference to nil so that ARC would release it, and hopefully call -dealloc on it, but either it's not doing that, or -dealloc doesn't close that second FD either.

    In any case, when I go to open that port again, I get an error saying the resource is busy (if I quit my app, all FDs get closed).

    This sure seems like a bug to me. Am I doing something wrong?

    Thanks,
    Rick
  • On Jul 13, 2012, at 7:46 PM, Rick Mann <rmann...> wrote:

    > I'm using NSFileHandle in an ARC app on OS X Lion to read from a serial port.
    >
    > Everything works fine 'till I go to close the port. I open the port with POSIX calls, set up some stuff, then instantiate an NSFileHandle with the file descriptor I got from open().
    >
    > Then I call -readInBackgroundAndNotify, and a second file descriptor gets opened (I see this by using lsof).
    >
    > That FD gets closed the moment some data comes in and a notification gets posted, but I just go right back and call -readInBackgroundAndNotify again to get the next data.
    >
    > The problem is when I go to close the port. I still have a pending -readInBackgroundAndNotify, and so the port is opened twice. When I call -closeFile on the NSFileHandle, it closes the FD I initially opened, but leaves the second FD open.
    >
    > I tried setting the NSFileHandle reference to nil so that ARC would release it, and hopefully call -dealloc on it, but either it's not doing that, or -dealloc doesn't close that second FD either.
    >
    > In any case, when I go to open that port again, I get an error saying the resource is busy (if I quit my app, all FDs get closed).
    >
    > This sure seems like a bug to me. Am I doing something wrong?

    NSFileHandle dups the file descriptor to avoid bugs where the descriptor is closed from under it. That's expected.

    NSFileHandle retains itself during the background operation to avoid being deallocated while it's still in progress. I think the -closeFile call is supposed to cancel the background operations which in turn should release that extra retain, but perhaps something in there is not working correctly.

    What does the Allocations instrument say about the retain/release history? If it looks like -readInBackgroundAndNotify is performing an extra retain that doesn't get released then you should file a bug report.

    --
    Greg Parker    <gparker...>    Runtime Wrangler
  • On Jul 16, 2012, at 12:02 , Greg Parker wrote:

    > What does the Allocations instrument say about the retain/release history? If it looks like -readInBackgroundAndNotify is performing an extra retain that doesn't get released then you should file a bug report.

    Hrm, I don't know how to use Allocations well enough to get any useful data. I can't seem to stop in the debugger while it's running, and Allocations never shows an NSFileHandle object being allocated (even though I know it is).

    Don't really know how to check this.

    --
    Rick
  • On Jul 16, 2012, at 12:02 , Greg Parker <gparker...> wrote:

    >
    > On Jul 13, 2012, at 7:46 PM, Rick Mann <rmann...> wrote:
    >
    >> I'm using NSFileHandle in an ARC app on OS X Lion to read from a serial port.
    >>
    >> Everything works fine 'till I go to close the port. I open the port with POSIX calls, set up some stuff, then instantiate an NSFileHandle with the file descriptor I got from open().
    >>
    >> Then I call -readInBackgroundAndNotify, and a second file descriptor gets opened (I see this by using lsof).
    >>
    >> That FD gets closed the moment some data comes in and a notification gets posted, but I just go right back and call -readInBackgroundAndNotify again to get the next data.
    >>
    >> The problem is when I go to close the port. I still have a pending -readInBackgroundAndNotify, and so the port is opened twice. When I call -closeFile on the NSFileHandle, it closes the FD I initially opened, but leaves the second FD open.
    >>
    >> I tried setting the NSFileHandle reference to nil so that ARC would release it, and hopefully call -dealloc on it, but either it's not doing that, or -dealloc doesn't close that second FD either.
    >>
    >> In any case, when I go to open that port again, I get an error saying the resource is busy (if I quit my app, all FDs get closed).
    >>
    >> This sure seems like a bug to me. Am I doing something wrong?
    >
    >
    > NSFileHandle dups the file descriptor to avoid bugs where the descriptor is closed from under it. That's expected.
    >
    > NSFileHandle retains itself during the background operation to avoid being deallocated while it's still in progress. I think the -closeFile call is supposed to cancel the background operations which in turn should release that extra retain, but perhaps something in there is not working correctly.
    >
    > What does the Allocations instrument say about the retain/release history? If it looks like -readInBackgroundAndNotify is performing an extra retain that doesn't get released then you should file a bug report.

    I don't know how to use the Allocations instrument. I've filed a bug: 12004852. It contains my Xcode project.

    --
    Rick
  • On Aug 1, 2012, at 3:33 AM, Rick Mann <rmann...> wrote:

    > I don't know how to use the Allocations instrument. I've filed a bug: 12004852. It contains my Xcode project.

    The word "RTFM" comes to mind. Instruments isn't the most intuitive app in the world, but it does have documentation, and if you're smart enough to learn Cocoa programming you should be able to get the hang of it (I managed to.)

    Filing bug reports without doing due diligence yourself first is wasting people's time (most likely the bug will get bounced back to you several months later with a comment saying "try using the Allocations instrument". D'ohhh.)

    —Jens
  • On Aug 1, 2012, at 9:37 , Jens Alfke <jens...> wrote:

    >
    > On Aug 1, 2012, at 3:33 AM, Rick Mann <rmann...> wrote:
    >
    >> I don't know how to use the Allocations instrument. I've filed a bug: 12004852. It contains my Xcode project.
    >
    > The word "RTFM" comes to mind. Instruments isn't the most intuitive app in the world, but it does have documentation, and if you're smart enough to learn Cocoa programming you should be able to get the hang of it (I managed to.)

    Thanks for that incredibly helpful suggestion.

    I know how to run instruments. Show me the documentation that tells me how to actually do something with Allocations. If you look at my previous email on the subject, you can see that I ran Allocations way back when it was suggested, and found NO allocations of NSFileHandle.

    I did a fair bit of work on this already. I don't have time do all of Apple's job for them. I've provided them with the code necessary to reproduce the problem, they're the ones that will have to fix it.

    > Filing bug reports without doing due diligence yourself first is wasting people's time (most likely the bug will get bounced back to you several months later with a comment saying "try using the Allocations instrument". D'ohhh.)

    Then they will waste my time and theirs while I give them a similar explanation.

    --
    Rick
  • On 1 Aug 2012, at 3:58 PM, Rick Mann <rmann...> wrote:

    > I know how to run instruments. Show me the documentation that tells me how to actually do something with Allocations. If you look at my previous email on the subject, you can see that I ran Allocations way back when it was suggested, and found NO allocations of NSFileHandle.

    My book has a couple of chapters on Instruments, including a lengthy example of how to use the Allocations instrument.

    I am reluctant to self-promote, but it's responsive to your search for documentation.

    — F

    --
    Fritz Anderson -- Xcode 4 Unleashed: Now in stores! -- <http://x4u.manoverboard.org/>
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today