December 2006 - Darwin-kernel

ThreadSleep was: IOCommandgate->commandSleep meaning of the flags
by Godfrey van der Linden 20 Dec '06

20 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: IODMACommand->genIOVMSegments
by Michael Smith 19 Dec '06

19 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Hello List, Yuck. You should. Have you tried it? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… devmaillists wrote: I need some additional information to genIO64VMSegments. Google does not really find something about this. We are writing a driver for a PCI Card and DMA Data should be transferred in multiples of 4K ( page size ). This is because of the memory layout on the card and to let the card take a breath between the transfers. If if I set initWithSpecification maxSegmentSize to 4K ( I expect this to be the native page size), do I get only 4K "physically continous segments" with IOVMSegments. Sure the last one will be short. Is there a way to tell the IOMemoryDescriptor to generate physically continous segments with a defined size?. The IOMemoryDescriptor doesn't "generate segments"; it simply allows you to temporarily freeze the current layout of a particular region of memory. The VM system is responsible for the allocation of physical pages, and it does not as a general rule make any attempt to organise pages contiguously. Is there a general rule how large a MemDesc can be to get prepared without igniting a lot of paging? It depends entirely on the working set size for the system at the time you prepare the IOMemoryDescriptor (I assume that's what you mean by 'MemDesc'). As a general rule, since you can't know what the system is doing, you should try to balance the time your device takes to do work on the descriptor vs. the overhead involved in setting it up and tearing it down. A ratio of 2:1 between work time and setup/teardown time is a good lower limit; beyond 10:1 is often not worth pursuing due to diminishing returns. This email sent to site_archiver(a)lists.apple.com

1 0

IODMACommand->genIOVMSegments
by devmaillists 19 Dec '06

19 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

kern_event socket deadlock
by Matt Darland 19 Dec '06

19 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com >From kern_event.c (with my notes prefixed with MTD): static int kev_detach(struct socket *so) { // MTD: kev_detach caller has sock_locked(so). // MTD If someone is posting a message, then we have to wait here. lck_mtx_lock(evt_mutex); return 0; } int kev_post_msg(struct kev_msg *event_msg) { // ... // MTD: Non-pertinent code. Removed. lck_mtx_lock(evt_mutex); // MTD: Now kev_detach() has to wait for this mutex to be unlocked. for (ev_pcb = LIST_FIRST(&kern_event_head); ev_pcb; ev_pcb = LIST_NEXT(ev_pcb, ev_link)) { if (ev_pcb->vendor_code_filter != KEV_ANY_VENDOR) { if (ev_pcb->vendor_code_filter != ev->vendor_code) continue; if (ev_pcb->class_filter != KEV_ANY_CLASS) { if (ev_pcb->class_filter != ev->kev_class) continue; if ((ev_pcb->subclass_filter != KEV_ANY_SUBCLASS) && (ev_pcb->subclass_filter != ev->kev_subclass)) continue; } } m2 = m_copym(m, 0, m->m_len, M_NOWAIT); if (m2 == 0) { m_free(m); lck_mtx_unlock(evt_mutex); return ENOBUFS; } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I think I've found a deadlock condition between kern_event sockets disposal and data posting, but I want to make sure my theory passes muster with the Darwin kernel guys before filing a radar. Once this happens, the whole system goes unstable in various ways. I can reproduce this condition reliably. struct kern_event_pcb *ev_pcb = (struct kern_event_pcb *) so- >so_pcb; if (ev_pcb != 0) { // MTD: But we're still on the list ?!? What if kev_post_msg() tries to append data to this socket? LIST_REMOVE(ev_pcb, ev_link); lck_mtx_unlock(evt_mutex); FREE(ev_pcb, M_PCB); so->so_pcb = 0; so->so_flags |= SOF_PCBCLEARING; } // MTD: Oh oh, this socket is locked down, in kev_detach(). Now we're hung. socket_lock(ev_pcb->ev_socket, 1); if (sbappendrecord(&ev_pcb->ev_socket->so_rcv, m2)) sorwakeup(ev_pcb->ev_socket); socket_unlock(ev_pcb->ev_socket, 1); } } This email sent to site_archiver(a)lists.apple.com

1 0

Re: utimes() no good for symbolic links?
by Terry Lambert 19 Dec '06

19 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Here is the short answer:... Here is a long answer you are not going to like:... Here is a longer answer that you're really not going to like:... I don't know, given only the information you've given me. (2) The user ownership will be the creating user - (7) set your umask back to what it was (8) regain root privilege for your helper (setuid(0)) (11) remove the "group helper" directory - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 17, 2006, at 7:02 PM, Jerry Krinock wrote: on 06/12/16 21:51, Terry Lambert at tlambert(a)apple.com wrote: Thanks very much, Terry. I had come across some of this history, but can now appreciate how dumb we are indeed when we look at an icon in a Finder window and say "That's a file", as if we know what that means! My assignment was to write code which would copy "symlinks with all their metadata". But I've not yet found a way to copy the datetimes metadata of a symlink. One unexplored possibility might be to copy the symlink, somehow setting it to to be a "regular file", so that I can fool utimes() or setattrlist() into setting its datetimes metadata to that of the "original symlink", and then after that, sneakily change the file type to be a symlink. But this seems too wacky to use in real life, and I might well run into another showstopper anyhow, because I noticed accidentally that setattrlist() fails with errno=22 "invalid argument" if I ever try and set the file type, ATTR_CMN_OBJTYPE. (By the way, this failure is undocumented also.) So, unless someone has another idea, I am going to resolve this issue by telling my user: "When you copy a symlink, the datetimes metadata of the copy will be the time of the copy, instead of the times on the original symlink, because a symlink cannot be copied, it can only be 'recreated'. This is OK because a symlink is not really a file. And who the hell cares ^when^ you created, modified or accessed a symlink anyhow, because it's only a stupid symlink, for God's sake!" Does that make sense? The answer would depend on the specific version of MacOS X you were doing this for, and what the underlying FS was that you were copying from and to. I suspect that you are running on 10.4.x on HFS+, and if so, the answer is that: (1) The permissions are going to be 0777, as modified by your umask at the time the symlink is created (3) The group ownership will be the group of the directory in which you created the symlink (4) Nothing you do will change the symlink permissions after the fact (and the OS is free to ignore them in deciding whether or not someone is allowed to follow the link) (5) You could also explicitly set the user and group on the symlink later, using the lchown() system call, if you could live with the security implications. So if you wanted to tie yourself in particular HFS+ and version 10.4.x of the OS, you could manipulate the symlink permissions at create time (and *only* at create time!) by modifying your umask to be the inverse of the permissions you want, creating the link, and setting your umask back. Note that this will only work for the normal permissions bits, which is to say 0777, not including the suid/sgid/sticky bit, and not including any of the chflags flags in the upper bits of the st_mode field from lstat. So, for example, without an SUID "helper" program, it would be impossible to create a symlink with no permissions, change the ownership, and then open up the permissions (e.g. do the same thing you would do with a file to ensure that no one can access it until it has the proper ownership set on it before any access permissions are granted, e.g. to create something that's inaccessible to an exclusion group). This is particularly problematic for the group membership. To work around all _that_, you would need to have your SUID "helper" do an even more complicated dance: So here's how you would do it in such a way that, if the underlying FS supported it at all, you could portably and securely do what you want: (1) create a "group helper" directory with the proper group ownership on the same FS as place the link was eventually going to live (2) change the group ownership of the directory to the target group (requires that you be root, if you are not a member of the group) (3) set your effective GID (setegid(XXX)) to the group you want the link to have (requires that you be root, if you are not a member of that group) (4) set your effective UID (seteuid(YYY)) to the owner you want the link to have (requires that you be root, if you are not already that user) (5) set your umask to the inverse of the permissions you wish the link to have (6) create the link in the helper directory (rather than where you actually wanted it to live) (9) change your effective group back to what it was (have to do #8 first, since if you weren't a member of the group, then this would otherwise be denied) (10) rename the link to the destination directory you actually wanted it created in ...in other words, there no way to close the permissions/owner race window with the lchown() (and lchmod(), if your OS supports it) unless you start with the link being the right group/owner/permissions atomically. Steps #1-2 and #10-11 are required if the FS or OS is "BSD-like", and groups on created FS objects are inherited from the containing directory (this can either be an OS-level thing, or it can be a per-FS thing, depending on what level the PSOX security model is implemented at). #3 and #9 are required if the FS or OS is "System V-like", and groups on created FS objects are inherited from the creating processes GID. And _still_ you would have no guarantee that the OS or underlying FS would treat the link as a first or second class object, or if it did, whether the visible ownership/permissions came from the symlink itself, or from the directory container. Personally, I would not recommend this approach, since whether the symlink permissions are from the link FS object or from the directory containing the link or purely synthetic is going to vary from version to version of the OS... for example, this would not work on MacOS X 10.3.x, since most the information for symlinks was taken from the directory. There's also the slight problem of ensuring your SUID helper program doesn't have any exploitable bugs. IMO, symlink information should be treated as cosmetic and visible to the whole world, since you don't know what the underlying OS or FS is going to do with the information. If you write code that depends on it, then you are going to end up breaking somewhere, at some point, when the underlying FS happens to have slightly different implementation details/semantics. If you need to control whether or not a symlink is deletable, put it in a directory with 01xxx set on it (i.e. like /tmp), where it's not possible for non-owners (except "root", of course) to delete a file (or symlink) that was created there. Anything else opens you up to making bad decisions that could break your security model when you run into an OS/FS that doesn't support the attributes you're trying to control. This email sent to site_archiver(a)lists.apple.com

1 0

Re: utimes() no good for symbolic links?
by Jerry Krinock 18 Dec '06

18 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcciUQG5QCPBk45EEducvAAWy6NyrA== Thread-topic: utimes() no good for symbolic links? User-agent: Microsoft-Entourage/11.2.5.060620 on 06/12/16 9:17, Quinn at eskimo1(a)apple.com wrote: > Try getting the times with <x-man-page://2/getattrlist>. That has an > option to not following leaf symlinks (FSOPT_NOFOLLOW) and, if > anything can return this information correctly, that'll be it. Well, to ^return^ (read) the metadata datetimes was not my problem; lstat(2) can do this. The problem was to "set" (write) these datetimes. This should be do-able by utimes(), but it "just doesn't work". However, Quinn, your tip to getattrlist() pointed me to what I was possibly looking for, setattrlist(). So, I wrote a tool to test setattrlist(), with FSOPT_NOFOLLOW. TEST RESULTS: I find that setattrlist() has the same "undocumented behavior" as utimes(): When I tell it to set the metadata datetimes of a symlink, it smiles and returns 0, but "just doesn't work". The datetimes remain unchanged. (I tested creation, modification and access datetimes.) When this same tool is called upon a regular file, it "just works". Should I bother to file bug reports? To the Apple DTS Bug Reporter or is there a separate Darwin bug tracker? on 06/12/16 21:51, Terry Lambert at tlambert(a)apple.com wrote: > Here is the short answer:... > Here is a long answer you are not going to like:... > Here is a longer answer that you're really not going to like:... Thanks very much, Terry. I had come across some of this history, but can now appreciate how dumb we are indeed when we look at an icon in a Finder window and say "That's a file", as if we know what that means! My assignment was to write code which would copy "symlinks with all their metadata". But I've not yet found a way to copy the datetimes metadata of a symlink. One unexplored possibility might be to copy the symlink, somehow setting it to to be a "regular file", so that I can fool utimes() or setattrlist() into setting its datetimes metadata to that of the "original symlink", and then after that, sneakily change the file type to be a symlink. But this seems too wacky to use in real life, and I might well run into another showstopper anyhow, because I noticed accidentally that setattrlist() fails with errno=22 "invalid argument" if I ever try and set the file type, ATTR_CMN_OBJTYPE. (By the way, this failure is undocumented also.) So, unless someone has another idea, I am going to resolve this issue by telling my user: "When you copy a symlink, the datetimes metadata of the copy will be the time of the copy, instead of the times on the original symlink, because a symlink cannot be copied, it can only be 'recreated'. This is OK because a symlink is not really a file. And who the hell cares ^when^ you created, modified or accessed a symlink anyhow, because it's only a stupid symlink, for God's sake!" Does that make sense? Jerry Krinock _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: P_WEXIT
by Terry Lambert 17 Dec '06

17 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 16, 2006, at 9:51 AM, Joseph Oreste Bruni wrote: On Dec 15, 2006, at 8:24 PM, Terry Lambert wrote: Let me say up front that I don't believe this is a kernel problem, and the "showallstacks" command should confirm that there are still stacks running in the process. You may end up (if it has already been taken off the active process list) having to track down the task from the zombie list, if it doesn't show up in the task list - meaning it won't show in the "showallstacks". Perhaps I don't understand at Apple's implementation layer what happens to a thread during a pthread_join(). My understanding of pthread_join() is that the calling thread blocks until the referenced thread terminates either explicitly by a call to pthread_exit(), implicitly by returning from the thread's main routine, or by terminating at a cancellation point after having been cancelled, that pthread_join() is analogous to waitpid() (without the WNOHANG option). So, a stack continues to exist even after it has been joined? Are stacks then cleaned up asynchronously? Or is there a subsequent *_np API I need to call to get stacks to get cleaned up? Every thread that I created I successfully joined without exception since I logged the thread IDs and accounted for them all. The answer to this question depends on whether you are using user managed stacks. If you are not using user managed stacks (i.e. you did not use pthread_attr_setstack()), then the stack will be freed automatically, either when you exit (if it's a detached thread), when you join the thread successfully (if it's not a detached thread) or on process exit. If you explicitly manage the stacks yourself instead, then you pass the address of an allocated stack (and should probably call pthread_attr_setstacksize() when you call pthread_attr_setstackaddr(), if you make your area anything other than DEFAULT_STACK_SIZE, which is 512K). But for most uses, it's cleaned up for you (this all happens in user space in Libc, so it's not hung in the kernel over this particular issue). I'll see what I can do about the kernel debugging. Assuming there is yet another thread hanging around, I have no idea what I would be changing in my code beyond what I'm doing now. There are a lot of things that could cause this to be a problem; for example, if you have a thread blocked on a semaphore owned by a thread that you destroy; there's no resource tracking that would cause that thread to wake up until someone (*anyone* with rights on it) decrements the semaphore, or the pthread in question is signalled via pthread_kill(). Using "top", the number of threads ("#TH") in the running program is exactly equal to the number I'm creating plus the main thread, so I have no idea what other threads could be hiding. If a process is in P_WEXIT, by the time it gets to where it's going to exit, there should be 1 thread on its way back through the AST to calling proc_exit() (this _does_ happen in the kernel). Effectively, you have to drain out all other active threads for the thread that called exit() to run to completion to an actual exit of the process. P_EXIT is generally never visible unless you hit at exactly the right submicrosecond in a single threaded program; for a multithreaded program, the state lasts until the other threads which are blocked in the kernel unblock and terminate. This email sent to site_archiver(a)lists.apple.com

1 0

Re: utimes() no good for symbolic links?
by Terry Lambert 17 Dec '06

17 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Here is the short answer: Don't write code that depends on being able to do this. Here is a long answer you are not going to like: Here is a longer answer that you're really not going to like: <http://www.opengroup.org/onlinepubs/009695399/functions/lchown.html> -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 15, 2006, at 11:27 PM, Jerry Krinock wrote: It looks to me like utimes() does not work for symbolic links. If the symlink is valid, it returns 0, but sets both atime and mtime to the current time instead of the time I pass in as argument. If the symlink is broken, it returns -1 and also sets atime and mtime to the current time. The documentation man utimes (2) does not mention that there is any problem with symbolic links. Does anyone know, is this a bug in utimes(), a documentation bug, or my misunderstanding? Also, does anyone know of a good function that works for setting atime and mtime of all files, including symlinks? I don't think that FSSetCatalogInfo works for symlinks either, but it's too late to try tonight. And even if it does, it ain't documented. You can try "getattrlist" and "setattrlist". Whether it works will depend on the FS implementation, and there will be no indication in some FSs that it's operating on the link target rather than the link itself. Basically, you can only do it if you know for sure it already works, and you only ever intend to deploy your applciation on a specific FS type mounted by a specific OS type. You need to realize that symbolic links are generally not considered to be first class file system objects (real files, with just a different type, with all their own metadata) or second class file system objects (real files, with a different type, but most metadata from the parent directory, not from the link object), and many filesystems can implement them as immediate files (link data store in the inode) or virtual files (link data stored in the directory entry, with no on disk representation). Historically, HFS did not support symbolic links at all. When symbolic links were added, they were added as second class file systems objects: it was impossible to set the permissions or ownership on them directly, and readability and writeability were controlled by the ownership and flags on the directoy, not the link. When you did an ls -l, the information about the directory, not the link was returned. So the answer for HFS depends on your version of MacOS, and it's been evolving over time - you can't depend on your code acting the same from release to release of the OS, or even from software update to software update. There were several incarnations in UFS (FFS) as well. Initially, links were implemented as second class FS objects. Later, early in the life of FreeBSD, they were reimplemented first as immediate files, and then later as virtual files. In the later incarnation, you only ended up with an inode object if the lnk length was too long to fit into a directory entry block (512b - directory entry bookkeeping information, including a flag as to whether or not the entry was a symlink). Eventually, this was dropped, since the performance advantage was not sufficient to justify the complexity of the implementation. So basically, you should never depend on being able to set symlink ownership or permissions; further, you should expect that if you happen to be using an FS that doesn't support setting link ownership or permissions, that any changes you make with normal FS APIs (like utimes) will result in an operation on the link target (if there is one) or the directory in which the link resides. Typically, if you feel you need to control this type of thing, there's something wrong with your application or your security model (specifically, you are assuming a specific implementation, which might not be true on other system where you might want to one day run your code). To address this, there have been a couple of APIs introduced, initially on Linux. These are lchmod() and lchown(); there is no equivalent for lutimes() or lchflags(), and so on. These interfaces have a number of very serious technical flaws inherent in their design, and this is inherited in the design of software that relies on them: First, only the lchown() operation is specified by the POSIX standard; this is problematic for a number of reasons. The major one is that that means any vendor that implements more than simply the lchown() call is at risk of binary incompatibility if and when anything beyond this becomes standardized. If the (eventual) standard does not match the (premature) implementation, the consequence to the vendor is that they are no longer standards compliant. Because no vendor can afford this, they would have to change to match the standard, and this could introduce a binary compatibility issue - and break software that relied on the old behaviour. Basically, and application that used the old interface and broke would need to offer updates to their irate customers an update, and both the application writer and the vendor would look bad. Second, lchown() standard was rushed through the standardization process and shows it: The most egregious problem with the design of this API is that it specifies that the error in the case of non-support of the API is the error code EOPNOTSUPP; but this is a bogus error code. The error code means "Operation not supported on socket" - in other words, it's a networking specific error code, and symlinks are not sockets. The correct error code from a design perspective would be ENOTSUP, meaning "Operation not supported". Third, because these APIs are filesystem option, it encourages people to write software which depends on them working, because they happen to have a filesystem that both implements symbolic links as a first class FS object, and supports the API. Then when you try to perform the same operation against an FS that *doesn't* support them, your software breaks. Then the application vendor gets a bad review, or they get a phone call from an angry customer who wants the problem fixed. Finally, they are inherently racy and insecure. Specifically, any operation you perform involving symlink-specific APIs will end up being both non-atomic and non-idempotent. For example, say you wanted to change the owner of an object; first, you have to find out whether or not it's a link, so you call lstat() to see if it's a link, then if it is, you call lchown() to change it's mode, otherwise, you call chown(). This is dangerous; if the object was a link, it could be changed to a non-link between your call to lstat() and subsequent call to lchown(); likewise, if it's a non-link, it could be changed to a link between the time you call lstat() and the subsequent call to chown(). The first race is never avoidable. You can avoid the second race by always using lchown(), which will always get you the link rather than the symlink as the target - but what if that is not really what you wanted? The result is either that you chown() a file in a way that you didn't want to chown() it, or you end up with a link that can be redirected to another file at some other point after you expect you are already doing "secure" operations against it. The way you avoid this with files is to open the file, at which point you have a persistent handle on it, and then you use fchown() on it. There's no moral equivalent for an "open" symlink... even if the symlink is stored as a first or second class FS object, there's no guarantee that you will be able to get an open fd referencing it (FreeBSD and Solaris allow this one _some_ FS's by honoring the O_NOFOLLOW flag to open() from user space, but you can't open the file for read or write - you have to just open it with no intent of reading or writing). And on FS's where it's not, you are guaranteed that you *will not* be able to get an fd (it's just like trying to open a directory for read or write, rather than using file creation and deletion operations or opendir() - usually buit on a directory iteration API like getdirentries()). This email sent to site_archiver(a)lists.apple.com

1 0

Re: P_WEXIT
by Joseph Oreste Bruni 16 Dec '06

16 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 15, 2006, at 8:24 PM, Terry Lambert wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Let me say up front that I don't believe this is a kernel problem, and the "showallstacks" command should confirm that there are still stacks running in the process. You may end up (if it has already been taken off the active process list) having to track down the task from the zombie list, if it doesn't show up in the task list - meaning it won't show in the "showallstacks". -- Terry Perhaps I don't understand at Apple's implementation layer what happens to a thread during a pthread_join(). My understanding of pthread_join() is that the calling thread blocks until the referenced thread terminates either explicitly by a call to pthread_exit(), implicitly by returning from the thread's main routine, or by terminating at a cancellation point after having been cancelled, that pthread_join() is analogous to waitpid() (without the WNOHANG option). So, a stack continues to exist even after it has been joined? Are stacks then cleaned up asynchronously? Or is there a subsequent *_np API I need to call to get stacks to get cleaned up? Every thread that I created I successfully joined without exception since I logged the thread IDs and accounted for them all. I'll see what I can do about the kernel debugging. Assuming there is yet another thread hanging around, I have no idea what I would be changing in my code beyond what I'm doing now. Using "top", the number of threads ("#TH") in the running program is exactly equal to the number I'm creating plus the main thread, so I have no idea what other threads could be hiding. smime.p7s

1 0

Re: utimes() no good for symbolic links?
by Quinn 16 Dec '06

16 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I'm getting a little off topic with the Carbon stuff, but if there is a solution to this problem, I suspect it is at the BSD layer. Any ideas? S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 8:20 -0800 16/12/06, Jerry Krinock wrote: Try getting the times with <x-man-page://2/getattrlist>. That has an option to not following leaf symlinks (FSOPT_NOFOLLOW) and, if anything can return this information correctly, that'll be it. This email sent to site_archiver(a)lists.apple.com

1 0