site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Aug 29, 2008, at 11:16 PM, Luke Daley wrote: HTH - Jordan _______________________________________________ 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 have been developing a library that interposes several system calls . This is used in TextMate to intercept attempts to read from STDIN for the purpose of displaying a dialog to allow the user to enter input. This works for everything I have tested so far (e.g. Java, Ruby, Python, svn < 1.5), but not svn 1.5. Ah, you naughty boy... Just wait until you happen to execute something which, for security or other reasons, completely cleanses its environment and kicks the crutches out from under you on the next fork(). :-) Still, it's hard to blame you for using dyld inter- positioning when we don't really provide you with any other choice for dealing with scenarios like this one (some nice hooks in Libsystem, for example, right below the point where all the API variants converge so you don't have do all that crazy entrypoint gymnastics... Hurm... Mumble... Moving on...). DISCLAIMER: This is all magic to me and I don't understand what __asm() is really doing and that could very well be my problem. All the __asm()s are doing in your example is spitting out extra assembler labels. The label emitted by each _asm() overrides the label that would have been used instead (e.g. "select$UNIX03" instead of "select"). To put it another way, it's a poor-man's versioned symbol hack with attribute tags instead of version numbers (and no help from the dynamic loader). Sometimes you have to work with what you've got! What happens with svn (say `svn log http://blah.com`), is that it calls select() with a single fd in the writefds set (presumably the fd that the network request is going out on) and a timeout of 3600. With svn < 1.5 with this implementation injected everything works fine. With svn 1.5, the syscall() returns immediately with -1 and the error is 'Bad file descriptor'. Well, one obvious question, I suppose, is what happens when you trace both svn 1.4 and svn 1.5 and then compare the results? It's easy enough to do stuff like this with drace, to wit: #!/usr/sbin/dtrace -s #pragma D option quiet syscall::select*:entry { printf("%s: %s(nfds=%d, readfds=%x, writefds=%x, errorfds=%x, timeout= %x)\n", execname, probefunc, arg0, arg1, arg2, arg3, arg4); } There, a stand-alone shell script which will show system-wide usage of select (for extra credit cleverness, I took care to display probefunc so you also get all the aliased calls). That should show you fairly quickly how the behavior is diverging, at which point you're at least a lot closer to putting your finger on the root cause. (I also left it as an exercise for the reader the task of translating the individual arguments to select() and printing them all purty-like). This email sent to site_archiver@lists.apple.com