April 2010 - Darwin-dev - lists.apple.com

Python file association problem
by Tobia Conforto 21 Apr '10

21 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I'm not sure what's the right list for this question. In Snow Leopard, double-clicking a .pyw file opens the script in a Terminal window, while it should not (and used not to, in previous OS X versions.) Both .py and .pyw files are Python scripts. The difference, quite uniform among OS, is that .py are console Python scripts, while .pyw are GUI Python scripts. In Snow Leopard, Python Launcher.app is correctly configured to open only "Python Script" files in a Terminal window, not "Python GUI Scripts". The problem is that the system maps both .py and .pyw extensions to the "Python Script" filetype (public.python-script) Who's the culprit? Is this an OS bug? How can I fix it on my system? I've perused the available documentation on Uniform Type Identifier, but they don't mention where the central database is, or how to patch it. Tobia _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Crash with FD_SET when there are more than 1024 open files
by Terry Lambert 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com All that said, there is no existing Apple software which uses the DNSServiceProcessResult() function, -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Apr 16, 2010, at 12:47 AM, Stefan Haller wrote: Terry Lambert <tlambert(a)apple.com> wrote: Huh? The crash I described happens with the following backtrace: It's not *explicitly* called, I should say, and most code trys to avoid that particular call graph. In general, you should separate your view from your controller (i.e. have a UI separate from the process being controlled) which would (mostly) avoid the issue. I've commented in the bug on the fix (I did that before I posted it to you). I would encourage you to encourage your customers to get away from 10.5 already, or check the utsname->version from uname(3) and limit the number of fd's you use, as a workaround. This email sent to site_archiver(a)lists.apple.com

1 0

Re: waitid() corrupts stack
by Greg Parker 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Apr 15, 2010, at 8:45 PM, Dave Keck <davekeck(a)gmail.com> wrote: > Greg Parker wrote: >> The kernel is writing the wrong size value into your siginfo_t variable. It looks like it's writing the 64-bit version of siginfo_t, but your 32-bit process has a smaller siginfo_t type. (siginfo_t has pointer and longint fields that change size.) >> >> If you don't need the siginfo_t's values, you should be able to get away with passing a bigger buffer to waitid(). > > Ah, thanks for the explanation. I presume all members preceding > si_addr should be safe? I think so. You can double-check by writing a test program to print `sizeof(siginfo_t->si_whatever) and `offsetof(siginfo_t, si_whatever)` on both architectures. On Apr 15, 2010, at 9:25 PM, Kevin Van Vechten wrote: > Please file a bug report at http://bugreporter.apple.com/ He already did: rdar://7871139 . Thanks, Dave. -- Greg Parker gparker(a)apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Crash with FD_SET when there are more than 1024 open files
by Jens Alfke 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Apr 16, 2010, at 1:40 AM, Stefan Haller wrote: > The code I posted is not my code; if it was, I would know how to make it > work. The code is in mDNSResponder which is part of Mac OS. The backtrace you posted is from a Cocoa app. mDNSResponder is not a Cocoa app, it’s a C-based daemon process. It sounds like you actually mean the client-side Bonjour libraries. Bonjour-dev might be a better list to post to; since I haven’t seen any of the Apple Bonjour experts replying to your post, they may not be reading darwin-dev. —Jens _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Crash with FD_SET when there are more than 1024 open files
by lists＠haller-berlin.de 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=haller-berlin.de; s=mail_2009081900; h=Message-ID:Date:From:Subject:In-Reply-To:To; bh=eJzMa73aJF+TG6zUYf0tcxCt5U5Ggddaqc/3L4VVm5I=; b=ZYo5lTM+BbRgW0k+jh9sZBUIPADSZK6T05+Zj43SsSBe/+1aNhV+DNQb6rfujMwmqxCayfFahacB3063IwmZQg4c59vw9FZDqMbkUTiVbb0iJve6GiyZ+e1YfLz1dDZs07t/lT3LFL/Uz6TtGEuKZ52cyL9tXzNAqfjn2Zpm3D0=; User-agent: MacSOUP/2.8.3 (Mac OS X version 10.6.3 (x86)) Stuart Smith <stuart(a)elgato.com> wrote: > > We are investigating a reproducible crash that happens in Bonjour code > > when we have many files open. The crash happens in > > DNSServiceProcessResult (part of mDNSResponder), which contains the > > following code: > > It seems you have a few alternatives: > recompile with a larger value for FD_SETSIZE > check that sd+1 is <= FD_SETSIZE before calling select(), although that > isn't particularly helpful.... > use poll() instead of select() Sigh; it seems I completely failed to make myself clear. Let me try again: The code I posted is not my code; if it was, I would know how to make it work. The code is in mDNSResponder which is part of Mac OS. I'm not even actively calling this code. All I'm doing is opening an NSSavePanel; this causes the offending code to run (presumably in order to populate the save panel's side bar with file servers). This seems to be outside of my control. I consider this a bug in Apple's code, and I reported it as such. My concern, however, is that other, similar code might be running in my process over which I have no control either. For example in other parts of Mac OS, or as part of plugins that my application loads. Also, for this particular bug it's not sufficiant for us to wait until Apple fixes it in a future 10.6.x update. Many of our users are still running 10.5 and don't want to upgrade. So I'm looking for ways to protect against this, for example by making sure that there are always enough small file descriptors available. -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Crash with FD_SET when there are more than 1024 open files
by lists＠haller-berlin.de 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=haller-berlin.de; s=mail_2009081900; h=Message-ID:Date:From:Subject:In-Reply-To:Cc:To; bh=rqaus1EYVneAU/HgqHKwcyHm/S4sM8ZD0OoFDzetFQM=; b=d/XKEedvJv36BElU1wsNDplQI6v43OERg3BwGEsheE/lP/6MG/U6IP3zpbWN+Hw5dqqM53LWe7ZH/z6BdxGsLX7gnLRBmoMTguXxSbGecFPU6oGoAbaiyfwuq3sf2IKnQLKwt1WRoNp5ncU1VLbeyCJlcXBa5U7TzfFYn3/p3H0=; User-agent: MacSOUP/2.8.3 (Mac OS X version 10.6.3 (x86)) Terry Lambert <tlambert(a)apple.com> wrote: > On Apr 15, 2010, at 8:54 AM, Stefan Haller wrote: > > We are investigating a reproducible crash that happens in Bonjour code > > when we have many files open. The crash happens in > > DNSServiceProcessResult (part of mDNSResponder), which contains the > > following code: > > > > static int more_bytes(dnssd_sock_t sd) > > { > > struct timeval tv = { 0, 0 }; > > fd_set readfds; > > FD_ZERO(&readfds); > > FD_SET(sd, &readfds); > > return(select(sd+1, &readfds, (fd_set*)NULL, (fd_set*)NULL, &tv) > > > 0); > > } > > Are you recompiling this code yourself? If so, here's the trivial fix > for this: No. This code is running whenever my application opens an NSSavePanel; I don't seem to have any control over this. > All that said, there is no existing Apple software which uses the > DNSServiceProcessResult() function, Huh? The crash I described happens with the following backtrace: #0 0x994df6d7 in DNSServiceProcessResult () #1 0x9416d500 in BonjourBrowser::socketCallBack () #2 0x93d8e1ae in __CFSocketDoCallback () #3 0x93d8dc97 in __CFSocketPerformV0 () #4 0x93d47ff1 in __CFRunLoopDoSources0 () #5 0x93d45c1f in __CFRunLoopRun () #6 0x93d450f4 in CFRunLoopRunSpecific () #7 0x93d44f21 in CFRunLoopRunInMode () #8 0x909eb0fc in RunCurrentEventLoopInMode () #9 0x909eaded in ReceiveNextEventCommon () #10 0x909ead36 in BlockUntilNextEventMatchingListInMode () #11 0x96567135 in _DPSNextEvent () #12 0x96566976 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x967de021 in -[NSApplication _realDoModalLoop:peek:] () #14 0x967dd79d in -[NSApplication runModalForWindow:] () #15 0x96a71379 in -[NSSavePanel runModal] () #16 0x96a6a9f1 in -[NSSavePanel runModalForDirectory:file:] () #17 <my code> As far as I can tell, BonjourBrowser::socketCallBack is in OSServices.framework, which is part of CoreServices.framework. The example program that I attached to <rdar://problem/7701369> demonstrates this nicely with minimal code. Here is all it takes to make it crash: static void raiseOpenFileLimit() { struct rlimit lim; if (getrlimit(RLIMIT_NOFILE, &lim) != 0) { perror("getrlimit:"); exit(-1); } lim.rlim_cur = (rlim_t)4000; if (setrlimit(RLIMIT_NOFILE, &lim) != 0) { perror("setrlimit:"); exit(-1); } } - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { // Alternatively, type "ulimit -n 2000" in a shell and start the // application from that shell. raiseOpenFileLimit(); #ifdef __LP64__ const int kLimit = 2044; #else const int kLimit = 1665; #endif // Use up file descriptors int i, fd; for (i = 0, fd = -1; fd < kLimit; i++) { fd = open("/dev/null", O_RDONLY); if (fd == -1) { perror("open:"); exit(-1); } i++; } printf("used up %d file descriptors, next file descriptor is %d\n", i, fd + 1); NSSavePanel *panel = [NSSavePanel savePanel]; // crash: [panel runModalForDirectory:@"/tmp" file:@"bla.txt"]; } -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: waitid() corrupts stack
by Kevin Van Vechten 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Please file a bug report at http://bugreporter.apple.com/ Sent from my iPhone On Apr 15, 2010, at 8:45 PM, Dave Keck <davekeck(a)gmail.com> wrote: >> The kernel is writing the wrong size value into your siginfo_t variable. It looks like it's writing the 64-bit version of siginfo_t, but your 32-bit process has a smaller siginfo_t type. (siginfo_t has pointer and longint fields that change size.) >> >> If you don't need the siginfo_t's values, you should be able to get away with passing a bigger buffer to waitid(). > > Ah, thanks for the explanation. I presume all members preceding > si_addr should be safe? > > David > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/kvv%40apple.com > > This email sent to kvv(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: waitid() corrupts stack
by Dave Keck 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=NUWy0xeoNgI6TUyjXbvn8x3gOmLrJS622AyL39HK5bc=; b=o7nbb8VOWzyB1nHl6X+WlY9xE5cV37m9S8m0IL2kQO2vrEPh/cwIOeJWsh2n7Fqq7u 4ZqSirpD0MHo//z3Fe/4SUBzwVUuS7OWraCljaytfZqRIp4QWUoYk7vjnIGlE3ZXT+W6 c7TFnHKJnE6nI+ayP2lJ+etbuDi1cUVAD1N3U= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=i5FKdT6sAMT6gLGX9Gndu0sna68j3a9X/7QTlKuEAmoMlEAY1N4VFeDodr5TBtKcPB v5S7KB+15muL+/yc2kF18IOhFXxWK8fWT9psfpzm19XmD0wt6XqLx0qd8YiyQ5pzAqdN GKRFkcXeU9bEJm5nSDwDKwgZE9h1QL3sSFn24= > The kernel is writing the wrong size value into your siginfo_t variable. It looks like it's writing the 64-bit version of siginfo_t, but your 32-bit process has a smaller siginfo_t type. (siginfo_t has pointer and longint fields that change size.) > > If you don't need the siginfo_t's values, you should be able to get away with passing a bigger buffer to waitid(). Ah, thanks for the explanation. I presume all members preceding si_addr should be safe? David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: waitid() corrupts stack
by Greg Parker 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Apr 15, 2010, at 7:20 PM, Dave Keck wrote: > On i386 10.6, waitid() corrupts the stack, resulting in a crash (bug #7871139): > > The program works when compiled for x86_64. Is waitid() safe to use > from 64-bit? Perhaps there's a workaround to use it under i386? The kernel is writing the wrong size value into your siginfo_t variable. It looks like it's writing the 64-bit version of siginfo_t, but your 32-bit process has a smaller siginfo_t type. (siginfo_t has pointer and longint fields that change size.) If you don't need the siginfo_t's values, you should be able to get away with passing a bigger buffer to waitid(). The 64-bit type is less than twice as big as the 32-bit type, so this should do the trick: siginfo_t info[2]; waitid(P_PID, pid, info, (WEXITED | WNOWAIT)); -- Greg Parker gparker(a)apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

waitid() corrupts stack
by Dave Keck 16 Apr '10

16 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=WF2MSKVS7GcKS/lnRLXfUjrUWZsCm/b1z1KGik3+dT0=; b=c1lor6XWTO79XbWMvrUqzaIGVUR7zdYtkPBs+yY3HajEft/1zsjpGa+Ed/80xyDbe9 XN4YloiUlvuRhogyfUNKlSIc7o5m1XjqiM7z8CqG+yxqgpzXTR+vthUEqpCD06t6JzO5 LAeMWUdi6rFnFdyHLWdzpTJdy4/IFaKhEHULY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=mWMPXNNutz4Pjrfq7+Gu1WdW3ueVwlv6mYwSRsXAuTvxhhHC67SJKNENsPjTZ2aBM+ N4NoVwizK5a9DpWBW8Xw0D828Yq84plmO46UfF0Yn7iEnQWxkz80UwCcLduO4z1OMKVY TBr7DwtBAIQl7/Hz8oJNMHDOF7x7ICrM4DQyw= Hey list, On i386 10.6, waitid() corrupts the stack, resulting in a crash (bug #7871139): ========================= // Compile using: // gcc -arch i386 waitid_crash.c -o waitid_crash #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> void letscrashyay(pid_t pid) { siginfo_t info; waitid(P_PID, pid, &info, (WEXITED | WNOWAIT)); } int main() { pid_t pid = 0; pid = fork(); if (!pid) return execl("/bin/ls", "/bin/ls", NULL); letscrashyay(pid); return 0; } ========================= The program works when compiled for x86_64. Is waitid() safe to use from 64-bit? Perhaps there's a workaround to use it under i386? Thanks, David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0