site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 20, 2009, at 1:58 PM, A.M. wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, #include <CoreFoundation/CoreFoundation.h> #include <unistd.h> #include <sys/event.h> struct __FileDescriptorHackStruct { int junkA; int junkB; int junkC; int internalKqueueDescriptor; }; Cheers, M -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkqN0pQACgkQqVAj6JpR7t5WkACgqpXpWadi9b492b2VsrmHmaaT R8MAoLC49eH9DdYLWXygxOavnVZO218K =OBAa -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I am using CFFileDescriptor and it noticed that it seems to leak its kqueue file descriptor. Here is sample code demonstrating the problem: Wow. So I managed to cook up an evil hack which properly closes the kqueue: static void junkCallback(CFFileDescriptorRef fdref, CFOptionFlags callBackTypes, void *info) {} int main(int argc, char *argv[]) { int i; for(i=0;i<3;i++) { CFFileDescriptorRef fdref = CFFileDescriptorCreate(kCFAllocatorDefault, 0, false, junkCallback, NULL); printf("%d\n",((struct __FileDescriptorHackStruct*)fdref)-

internalKqueueDescriptor);

close(((struct __FileDescriptorHackStruct*)fdref)-

internalKqueueDescriptor);

CFFileDescriptorInvalidate(fdref); CFRelease(fdref); } sleep(100000); return 0; } If one flips the CFFileDescriptorInvalidate() and close() lines, the kqueue fd stays open. At least I can stop the leakage now- any ideas? This email sent to site_archiver@lists.apple.com