September 2009 - Darwin-dev

Re: error -10810
by IainS 30 Sep '09

30 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hello Terry, We're being bitten again by this problem on OSX 10.5.8 and 10.6.1. On 5 Sep 2009, at 20:27, Terry Lambert wrote: Is this in the wrapper (dejagnu) or in the underlying expect? have you any pointer to a bug report that I can examine? google didn't give any meaningful return to my queries. thanks, Iain _______________________________________________ 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… More specifically, what's happening is that the current session is being hosed. FWIW: whether this is causing launchd to die .. or whether launchd dying is the cause of the hose remains to be seen. The tests that cause the issue are ones where gdb is attached. The tests pass, and do NOT cause the session to be trashed, if run by a non-root user from the command line. Not really. There is a bug in the "expect" they ship that eats a process slot per run because it doesn't actually check the test output fully. we see this with OSX/XCode released expect 5.42 (10.5) and 5.44.1.11 (10.6) and with fink 5.43 (on 10.5) since these things are Open source.. at least we could look at fixing the fault you identify - if it still present. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Unable to delete a file owned by myself.
by Martin Costabel 30 Sep '09

30 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Frederick C.Lee wrote: [] $~/workarea/tmp:rm *.m4a override rw-r--r-- Ric/Ric uchg for Ric & Irina in Czech Rep..m4a? y rm: Ric & Irina in Czech Rep..m4a: Operation not permitted Seeing that uchg seems to be set, try chflags nouchg "Ric & Irina in Czech Rep..m4a" -- Martin _______________________________________________ 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… or unlock it via "Get Info" in the Finder (wisdom gained from googling for "uchg"). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Unable to delete a file owned by myself.
by Michael Smith 30 Sep '09

30 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.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: Unable to delete a file owned by myself.
by Terry Lambert 29 Sep '09

29 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Environment: Mac OS X 10.6.1 I'm trying to delete an empty .m4a file from my hard drive. I'm the owner of the file. $~/workarea/tmp:whoami Ric ls -le@d -- 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 Sep 29, 2009, at 11:42 AM, Frederick C.Lee wrote: $~/workarea/tmp:ls -l ... -rw-r--r--@ 1 Ric Ric 0 Jun 8 2004 Ric & Irina in Czech Rep..m4a ... the file to see if it has an ACL on it preventing removal (it probably does; I see an "@" on the end of the permissions string). If it does, use chmod to remove the ACL, and then you will be able to remove the file. This email sent to site_archiver(a)lists.apple.com

1 0

Unable to delete a file owned by myself.
by Frederick C.Lee 29 Sep '09

29 Sep '09

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:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=sHOZvN4w63T0lklZS5ij/3j4Hl1V4qKYoTnQywMYluY=; b=MV6Uih6JZ89DPEYHDUwZWxDoA+HqATkdrkeigfF95r1+nM/ZvlpNqhVrbwyuL0QCLT nDeKG7EovMG+cRjLc3CIdx6ubGJGuApHohbbiYJWgw3QU95KIgve63f2xwtBdFecDanz bXt+hvfjgAMdF+rDu3cWMy8z6Ofr87R3H0/2o= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=welbnui8e7cmEWl1px1tKj4Ju3H7t2s+tmWBCH/1fo2O0JOtGrvz8leYZZQAyTnUmY bTJbXHkX64sbrrYEA2knT/MPFCco1JfJp/k8CXqw3vQ6fi2tAa73LzN9V1t/9tWktCMu bw/rFVocxmEY8WK+Q6dyaV3KAg3TmoIHpudRg= Environment: Mac OS X 10.6.1 I'm trying to delete an empty .m4a file from my hard drive. I'm the owner of the file. $~/workarea/tmp:whoami Ric $~/workarea/tmp:ls -l ... -rw-r--r--@ 1 Ric Ric 0 Jun 8 2004 Ric & Irina in Czech Rep..m4a ... Here I'm trying to forcing a delete: $~/workarea/tmp:rm -f "Ric & Irina in Czech Rep..m4a" rm: Ric & Irina in Czech Rep..m4a: Operation not permitted I'll try again... $~/workarea/tmp:rm *.m4a override rw-r--r-- Ric/Ric uchg for Ric & Irina in Czech Rep..m4a? y rm: Ric & Irina in Czech Rep..m4a: Operation not permitted How can I remove this file? Regards, Ric. _______________________________________________ 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: Floating-point exception handling
by David N. Williams 29 Sep '09

29 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: University of Michigan User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Terry Lambert wrote: > On Sep 28, 2009, at 3:13 PM, David N. Williams wrote: >> David N. Williams wrote: >> > [...] >> > >> > Even so, I still have a problem. When the example is run on >> > OS X intel, the only signal code supplied to the handler in the >> > si_code field of the siginfo_t structure, when it's invoked on >> > SIGFPE, is FPE_NOOP. OS X ppc and GNU/Linux both supply at >> > least FPE_FLTDIV and FPE_FLTINV -- other codes not tested yet. >> > [...] >> > >> > So am I doing something wrong? >> >> Nobody seems to have an idea about this? :-( After >> experimenting with more cases, AFAICT I'm not doing anything >> wrong -- the discrepancy is real. >> >> So let me advocate that the discrepancy be resolved to make the >> intel behavior for sigaction() the same as that for ppc and >> GNU/Linux. >> [...] >> >> Am I off base here? > > You aren't running Snow Leopard, where this is fixed, are you? No, I'm running 10.5.8, Leopard. (Actually I did say that before...) That's good news! Thanks for letting me know! -- 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: Floating-point exception handling
by Terry Lambert 29 Sep '09

29 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com David N. Williams wrote: > [...] > > Even so, I still have a problem. When the example is run on > OS X intel, the only signal code supplied to the handler in the > si_code field of the siginfo_t structure, when it's invoked on > SIGFPE, is FPE_NOOP. OS X ppc and GNU/Linux both supply at > least FPE_FLTDIV and FPE_FLTINV -- other codes not tested yet. > [...] > > So am I doing something wrong? Nobody seems to have an idea about this? :-( After experimenting with more cases, AFAICT I'm not doing anything wrong -- the discrepancy is real. So let me advocate that the discrepancy be resolved to make the intel behavior for sigaction() the same as that for ppc and GNU/Linux. Is it onerous to implement putting the FPE_xxx code for the floating-point exception which invokes SIGFPE into the si_code member of the siginfo_t received by the handler? Without that or equivalent information, alternate IEEE 754 signal handling seems crippled. Doing so seems to be the Single UNIX 3 spec. IANAL, so it's hard for me to judge whether the [XSI|RTS] label next to the spec for si_code quoted below means that it's technically optional. You aren't running Snow Leopard, where this is fixed, are you? -- 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 Sep 28, 2009, at 3:13 PM, David N. Williams wrote: Am I off base here? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Floating-point exception handling
by David N. Williams 28 Sep '09

28 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: University of Michigan User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) David N. Williams wrote: > [...] > > Even so, I still have a problem. When the example is run on > OS X intel, the only signal code supplied to the handler in the > si_code field of the siginfo_t structure, when it's invoked on > SIGFPE, is FPE_NOOP. OS X ppc and GNU/Linux both supply at > least FPE_FLTDIV and FPE_FLTINV -- other codes not tested yet. > [...] > > So am I doing something wrong? Nobody seems to have an idea about this? :-( After experimenting with more cases, AFAICT I'm not doing anything wrong -- the discrepancy is real. So let me advocate that the discrepancy be resolved to make the intel behavior for sigaction() the same as that for ppc and GNU/Linux. Is it onerous to implement putting the FPE_xxx code for the floating-point exception which invokes SIGFPE into the si_code member of the siginfo_t received by the handler? Without that or equivalent information, alternate IEEE 754 signal handling seems crippled. Doing so seems to be the Single UNIX 3 spec. IANAL, so it's hard for me to judge whether the [XSI|RTS] label next to the spec for si_code quoted below means that it's technically optional. Am I off base here? -- David ---------- QUOTE on sigaction() from http://www.opengroup.org/onlinepubs/000095399/functions/sigaction.html [XSI|RTS] If SA_SIGINFO is set and the signal is caught, the signal-catching function shall be entered as: void func(int signo, siginfo_t *info, void *context); where two additional arguments are passed to the signal-catching function. The second argument shall point to an object of type siginfo_t explaining the reason why the signal was generated; the third argument can be cast to a pointer to an object of type ucontext_t to refer to the receiving thread's context that was interrupted when the signal was delivered. In this case, the application shall use the sa_sigaction member to describe the signal-catching function and the application shall not modify the sa_handler member. The si_signo member contains the system-generated signal number. [XSI] The si_errno member may contain implementation-defined additional error information; if non-zero, it contains an error number identifying the condition that caused the signal to be generated. [XSI|RTS] The si_code member contains a code identifying the cause of the signal. ---------- _______________________________________________ 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: fread multiple files
by Tomasz Koziara 26 Sep '09

26 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks again for all replies Tomek On 25 Sep 2009, at 22:21, Terry Lambert wrote: _______________________________________________ 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… In fact one of my "optimization scenarios" was to open the N file triplets (data, index, label) in N threads. I think I will try it. The biggest bottleneck though seems to be the fact that XDR implementation uses fread internally and does not seem to buffer the red data too well. All my reading and writing goes through XDR calls hence, I don have control over the internal handling for file stream. I can still see some space for improvement as XDR stream can be attached to a memory block, which I could prior read in one go - this though depends on whether the stream "positions" returned by xdr_getpos are actually absolute byte positions in a memory block or something else. You could definitely be doing your three I/Os concurrently instead of serailly, assuming the index data is not needed to drive the I/O, at which point you could do your index I/O concurrently and then do your data file I/O after that (semiserially, in other words). But if you arranged your code to do the first index read up front before going into the loop, you could do your *next* index reads concurrently with your data I/O for your current indices. You could further increase concurrency , assuming the data is index linked instead of data linked (i.e. you don't need each set of data prior to the next set of data) by inlementing a producer/consumer model, and issuing your I/Os as fast as you can and queueing the buffered data records for processing (you'd want to rate limit the number of outstanding I/Os to limit the data you have in hand at one time, before you ask for more data). If your data comes in at a rate higher than 1.5 times faster than you can process it, if you have a sufficiently large pool of work item queue elements, you could establish high and low water marks on number of elements in the queue, and then only go back for more data when you hit the low water mark. -- Terry This email sent to site_archiver(a)lists.apple.com

1 0

Re: fread multiple files
by Terry Lambert 26 Sep '09

26 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com #include <spawn.h> #include <sys/wait.h> #include <stdio.h> #include <errno.h> extern char **environ; -- 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 Sep 25, 2009, at 11:07 PM, Steve Checkoway <s(a)pahtak.org> wrote: On Sep 25, 2009, at 4:24 PM, Terry Lambert wrote: We don't support all of POSIX RT. The option set that that's in is actially AIO, which is a subset of RT, and we don't se _POSIX_ASYNCHRONOUS_IO in <unistd.h> because we don't support one of the option flags to aio_fsync() in a POSIX compliant way. So this seems like a case where relying on the version test macros in unistd.h as a method of determining the usability of a function rather than a link test is incorrect. Except you can't run partial test sets when running the conformance tests, so it's impossible to know without the feature test macros whether or not the behaviour of the interface, to the extent it is implemented, is in fact POSIX compliant. And, indeed, I know for a fact that it is not; however, I also happen to know that, to the extent he would be using it as a replacement for read in the use model he's reported to us, it'd work well enough for him. Just glancing through the list for the first time, I see _POSIX_SPAWN is defined as -1 but I thought posix_spawn() was supported. That feature test macro is defined that way for two reasons, even though Apple makes extensive use of posix_spawn() practically everywhere {v}fork()/execve() was used in prior OS releases: 1) the gcc compiler is broken in that it can't handle a non-variable containing prototype using the "restrict" keyword interior to an array declaration, so it's not possible to implement the prototype in a completely compliant way. 2) we wanted some "bake time" before everyone and their dog jumped in and started using it, and not advertising it was the best way to let us change its behaviour in future releases, without breaking too many people. The following works for me, at least. It seems like the only sure way to check if something will work is to write test code trying it since one cannot rely on the version test macros nor on link tests. In retrospect, this is obvious. int main( int argc, char *argv[] ) { if( argc < 2 ) return 1; pid_t pid; int status; int ret = posix_spawnp( &pid, argv[1], NULL, NULL, argv+1, environ ); if( ret != 0 ) { errno = ret; // lazy perror( "posix_spawn" ); return 1; } ret = waitpid( pid, &status, 0 ); if( ret == -1 ) { perror( "waitpid" ); return 2; } if( WIFEXITED(status) ) printf( "Exited normally with status %d\n", WEXITSTATUS(status) ); else if( WIFSIGNALED(status) ) printf( "Terminated due to signal %d\n", WTERMSIG (status) ); else puts( "Something else" ); return 0; } You did the "errno = ret;"... a lazier programmer might not have done that, and if they didn't, and their program was multiththreaded, they'd maybe see one thing that we already know we have to fix about the implementation to make it more strictly compliant (i.e. it sometimes smashes errno, but not for all errors). Like I said, it needs some "bake time". Likewise, it'd be possible to use per-thread current working directories to implement the HPC interfaces openat(), etc.. You'd actually not want to use them mostly, since per-thread current working directories are vastly superior to those interfaces for most uses to which they are put (e.g. virtual hosting and cgi sandboxing in web servers, etc.), they are just hard to implement in a lot of OSs, so people hacked around it by using up a bunch if fds as directory handles instead (hint: consider any OS without a 1:1 threading model). But if we implemented the HPC library functions before they were actually standardized, people started depending on some quirk of the draft standard, and that was later eliminated by the standards committee, people who implemented to our version would be in trouble over portability, and we'd be in trouble over standards compliance. So rather than implement a bunch of _np versions of largely inferior standards track interfaces, we don't implement them, and we point people who ask for them at per thread current working directories instead. Of course, standards committees may not catch their mistakes; lchown (), for example, was standardized as returning an errno of EOPNOTSUPP for an FS implementation not supporting changing ownership of symlinks; that's "operation not supported on socket", as opposed to the correct errno value, which would have been ENOTSUP, "not supported". And that's totally side-stepping the questionable utility of an lchown() in a standard which omits lchmod(), or the questionable utility of a function it would be a completly standards compliantl implementation of to just always set errno EOPNOTSUPP. But depending on them making such a mistake all the time would be a mistake. So there are, and probably always will be, interfaces which are "use at your own risk", which you will be able to find without the benefit of an OS contract about their adherence to standards (and an implied contract to not change unless the standard changes). If you want your code to be portable, you won't use them even if you are clever and find them without the feature test macros. Or, as in this case, you'll make a conscious trade-off between a potential loss of portability vs. greatly increased performance, and hopefully bracket your code with derived #ifdef's rather than direct #ifdef's. This email sent to site_archiver(a)lists.apple.com

1 0