February 2008 - Darwin-dev - lists.apple.com

Re: Start of Volume on Mac Intel
by Gregory Weston 26 Feb '08

26 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com vishal chauha wrote: I am using FSGetVolumeInfo to get the properties of a volume. I want to get the starting sector of a volume in the hard disk. What are you really trying to achieve? _______________________________________________ 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… I lean toward the belief that this is one of those questions where the best answer is: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using weak linking and other techniques with non-Apple libs
by Peter O'Gorman 26 Feb '08

26 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.9 (X11/20071115) David Elliott wrote: > Actually they could reduce it to compat 5.0.0, current 7.0.0 and no > existing apps would break. David, I have to correct your impression that the number passed as an argument to the ld flag -current_version has some effect on the dynamic linker. Here's a quick test of that: $ cat foo.c int foo() { return 1;} $ cat main.c extern int foo(void); int main() { return foo(); } $ mkdir lib $ gcc -dynamiclib -o lib/libfoo.dylib foo.c -install_name `pwd`/lib/libfoo.dylib -compatibility_version 7.0.0 -current_version 7.0.0 $ gcc -o main main.c -Llib -lfoo $ ./main $ echo $? 1 Now to relink the shared library with a lower compatibility version (but keep current version the same). $ gcc -dynamiclib -o lib/libfoo.dylib foo.c -install_name `pwd`/lib/libfoo.dylib -compatibility_version 5.0.0 -current_version 7.0.0 $ ./main dyld: Library not loaded: /Users/peter/tmp/ldcheck/lib/libfoo.dylib Referenced from: /Volumes/Users/peter/tmp/ldcheck/./main Reason: Incompatible library version: main requires version 7.0.0 or later, but libfoo.dylib provides version 5.0.0 Trace/BPT trap So, you see, that the -current_version flag has no effect on the dynamic linker, the compatibility version is the only one checked by dyld. Peter -- Peter O'Gorman http://pogma.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: Using weak linking and other techniques with non-Apple libs
by David Elliott 26 Feb '08

26 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Peter, On Feb 25, 2008, at 10:57 AM, Peter O'Gorman wrote: [big snip] Right. Like I said, just having accurate library versioning (e.g. compatibility 5.0.0 current 7.0.0) would be enough. I can figure out myself which functions are present in which OS X releases. You're absolutely right. I refreshed my memory: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Con… -Dave _______________________________________________ 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… David Elliott wrote: I think you misunderstood me. This is exactly the case now. You cannot build against libiconv from Leopard and run on anything other than Leopard because dyld will kill your program immediately at startup because your program says it requires 7.0.0 and Tiger only has 5.0.0. No, I understood, but now that Apple have shipped Leopard with libiconv with a compatibility version of 7.0.0, they can not reduce it because any currently shipping binaries that were linked on Leopard will stop working on leopard. Not a good plan. Actually they could reduce it to compat 5.0.0, current 7.0.0 and no existing apps would break. However, I do see your other point. See below. If you require that your application run on Tiger and Leopard, you can always use the 10.4 SDK. But, if Apple had spent the time and effort to inspect all their open source projects and modify the headers and libraries then you would be able to use 10.5 features on 10.5 and put -mmacosx_version_min=10.4 in the compiler and linker flags to ensure that the new interfaces were marked weak. Apple has not done that for 10.5, with an enhancement request they may do it for 10.6. The problem is that using an older SDK is not an option when you must be able to link to newer versions of other libraries. That is inaccurate versioning, in my opinion. Applications linked to the new library may not be compatible with the old. What happens is that you see libSystem and most of the other Apple- developed libraries completely breaking this convention because they have deferred compatibility checking to a higher level. Indeed it is true that when you add an interface you must increment the compatibility version because some random person using the library in the normal way will expect those functions to exist. And therein lies the failing of dyld's versioning scheme. If I never use any of the added symbols, and I know I do not use them then there ought to be a way I can specify through some ld options that I can use an older version. Or better still perhaps I can specify an option that I'd like ld to scan for the symbols I actually use and set the compatibility version to the lowest possible containing all of those symbols. For that to happen the dylib would of course need to actually have some amount of per-symbol versioning which dylibs do not at this time have. That's okay though as it makes me feel a lot better about my scheme to simply grab /usr/lib/libiconv.dylib and bump its compatibility version down to 5.0.0. Its current version can stay as is to document that it really was linked against 7.0.0. I then need only place the hacked libiconv.dylib in one of the -L paths and all is well. To handle the added symbols I simply need to make sure to use the weak-linking features, if I even need those symbols at all. Thanks for taking the time to get my mind right on this again. I'll have to add per-symbol versioning to my growing list of dreams. Theoretically, it would be possible to implement by only changing the static link editor to record more information when making a library and to use that information when linking to it. Dyld need not even consider it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: getcontext() -> Bus error?
by Terry Lambert 25 Feb '08

25 Feb '08

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com -- 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 Feb 23, 2008, at 5:16 PM, Kevin Van Vechten wrote: On Feb 23, 2008, at 11:23 AM, Duckki Oe wrote: I was experiencing difficulties with getcontext/makecontext last night. (you know.. getting SIGBUS, seg fault) And I've figured out that Darwin's ucontext_t is not like that of linux's. ucontext_t on Darwin (I'm using Mac OS X 10.5.2.) does not contain the mcontext_t, which stores machine dependent context. And let users allocate the mcontext_t buffer and point it in uc_mcontext member of ucontext_t. Or it just assumes mcontext_t buffer follows the ucontext_t variable. You may need to look into the actual ucontext_t structure in /usr/include/sys/ucontext.h. It's better to allocate ucontext_t using malloc with the length of sizeof(ucontext_t) + sizeof(*((mcontext_t)0)). Note that mcontext_t is just a pointer. Now it should work fine. This is not documented on the man pages. On the other hand, Linux's ucontext_t CONTAINS the whole structure of mcontext_t and you don't have to care about additional buffer. This was the issue I originally replied to on this thread. The ucontext_t only includes mcontext_t when _XOPEN_SOURCE is defined prior to including the header files (see /usr/include/sys/_structs.h). We generally do not want people poking around in the mcontext, and we treat it as an opaque array of bytes. It only has real meaning when the header file has the explicit type information in scope. So if you are writing a threads package, or you are writing a debugger, it's meaningful; otherwise it's No User Serviceable Parts Inside. The primary use for it is for the use of the third argument to the SA_SIGINFO, the utility of which is limited to context chaining, the stack pointer, and the stack in use at the time the signal handler fires: <http://www.opengroup.org/onlinepubs/009695399/basedefs/ ucontext.h.html> In this mode, you get an mcontext that happens to be laid out on the signal stack. For i386, there are two possible implementation of the constext, depending on whether your applciation is 32 or 64 bit, and for each of these there is a conforming namespace (where the element names begin with __ to take them out of the implementation namespace), and a non-conforming (which exists solely for source backward compatibility until we can get people to fully update their code tot he conforming implementation). On PPC, the situation is more complicated, and there are a number of other layouts for the signal stack, due to binary compatibility issues, as well as the same namespace juggling. The mcontext itself is not intended for use except by the kernel, and by applications that specifically need to implement dumping of process state, such as debuggers; in fact, this is strictly specified by POSIX to place the contents of the mcontext outside the namespace: <http://www.opengroup.org/onlinepubs/009695399/functions/getcontext.html > "Conforming applications should not modify or access the uc_mcontext member of ucontext_t. A conforming application cannot assume that context includes any process-wide static data, possibly including errno. Users manipulating contexts should take care to handle these explicitly when required." Also, as has been previously noted, the getcontext/setcontext// makecontext/swapcontext implementation exists solely because it was deprecated by not removed from the UNIX03 standard, and so we had to support it. Expect it to disappear at some point, as soon as we no longer need it to pass conformance testing. So basically, you are playing with something that's probably going to bite down on you pretty hard, unless you read the kernel and libc sources, and then are very, very careful in using it (avoiding it entirely, if at all possible). Even then, you are likely not going to get explicit register window flushes, etc., unless you go out of your way to put the assembly barriers in yourself. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using weak linking and other techniques with non-Apple libs
by Peter O'Gorman 25 Feb '08

25 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.9 (X11/20071115) David Elliott wrote: > Hi Peter, Hi David, >> David Elliott wrote: > > I think you misunderstood me. This is exactly the case now. You cannot > build against libiconv from Leopard and run on anything other than > Leopard because dyld will kill your program immediately at startup > because your program says it requires 7.0.0 and Tiger only has 5.0.0. No, I understood, but now that Apple have shipped Leopard with libiconv with a compatibility version of 7.0.0, they can not reduce it because any currently shipping binaries that were linked on Leopard will stop working on leopard. Not a good plan. If you require that your application run on Tiger and Leopard, you can always use the 10.4 SDK. But, if Apple had spent the time and effort to inspect all their open source projects and modify the headers and libraries then you would be able to use 10.5 features on 10.5 and put -mmacosx_version_min=10.4 in the compiler and linker flags to ensure that the new interfaces were marked weak. Apple has not done that for 10.5, with an enhancement request they may do it for 10.6. > > Even if you never use the new libiconv functions, you still can't run if > you linked to libiconv. On a Linux system, this would not be the case. > The soname would be the same (e.g. libiconv.so.X) but the versioning > info would be incremented appropriately. On Darwin the appropriate > thing to do is leave the full name the same (e.g. > /usr/lib/libiconv.X.dylib) and increment the current version but not the > compatibility version. No, I have to disagree. If someone uses the new symbols in the new libiconv then their application will not work with the older libiconv, that is what the whole compatibility_version is about. Older applications which use only the functions in the older library will continue to work with the new library, but newer applications using functions only present in the new library will not work with the old. This is how it should be. When interfaces are removed then the install_name (soname) of the library should change and the compatibility_version etc start at the beginning again. If you have complaints or suggestions for the libtool versioning scheme on darwin, please bring them up on libtool(a)gnu.org, and I will answer them there. I do not think that the versioning scheme can now change, however, as it would introduce binary compatibility issues. > > What would happen in both cases on Linux and Darwin is that the app will > crash when trying to bind missing symbols if and only if it actually > uses the newer symbols. I do not think that crashing like that is the desired behavior, if that were desired then compatibility_version would be unnecessary. >> > Right. Like I said, just having accurate library versioning (e.g. > compatibility 5.0.0 current 7.0.0) would be enough. I can figure out > myself which functions are present in which OS X releases. That is inaccurate versioning, in my opinion. Applications linked to the new library may not be compatible with the old. Peter -- Peter O'Gorman http://pogma.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: Need advice on catching thorny hang
by Marc Epard 25 Feb '08

25 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -Marc _______________________________________________ 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… Frustrating, I know. There's also the stackshot facility, see man stackshot. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using weak linking and other techniques with non-Apple libs
by David Elliott 25 Feb '08

25 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Peter, On Feb 25, 2008, at 2:52 AM, Peter O'Gorman wrote: David Elliott wrote: Apple will never go back and lower the compatibility version, it would cause applications using libiconv built on Leopard to cease working (requiring version 7.0 but libiconv is 5.0). There are, however, a large number of open source projects that are responsible for many of the libraries in /usr/lib, it may be too burdensome to expect Apple to inspect and patch all of them like this. Still, does not hurt to ask. Thanks a bunch! -Dave _______________________________________________ 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 lieu of Apple changing the library to use compatibility version 5.0.0 current version 7.0.0 (which would probably be the better thing to do) is there some way I can do this myself? One hack I have tried is to simply grab the /usr/lib/libiconv from the 10.4 SDK and drop it in one of the directories on the linker's -L path. This seems to work without problem now but I'm thinking that if we were to ever use new symbols present only in the newer library versions, even if weak-linking to them similar to the above, we'd be in trouble. I think you misunderstood me. This is exactly the case now. You cannot build against libiconv from Leopard and run on anything other than Leopard because dyld will kill your program immediately at startup because your program says it requires 7.0.0 and Tiger only has 5.0.0. Even if you never use the new libiconv functions, you still can't run if you linked to libiconv. On a Linux system, this would not be the case. The soname would be the same (e.g. libiconv.so.X) but the versioning info would be incremented appropriately. On Darwin the appropriate thing to do is leave the full name the same (e.g. /usr/lib/ libiconv.X.dylib) and increment the current version but not the compatibility version. What would happen in both cases on Linux and Darwin is that the app will crash when trying to bind missing symbols if and only if it actually uses the newer symbols. That being said, I think that you ought to file an enhancement request on this. Currently, Apple builds open source projects as designed, and uses the library versions supplied by upstream. In the case where there is only added API however (such as the libiconv version bump) it would be better if Apple were to patch the headers to include AvailabilityMacros.h and mark the added api as available in mac os x version whatever and later. I am actually happy to do it myself when needed but the library versioning then prevents me from actually using the libraries on the old system. Right. Like I said, just having accurate library versioning (e.g. compatibility 5.0.0 current 7.0.0) would be enough. I can figure out myself which functions are present in which OS X releases. I forget which document it is that I read on Apple's site but a couple of years ago read that document and designed the scheme to get it right for Bakefile and thus wx. That is, make it so that libtool- style versioning translates both to ELF versioning as well as dyld versioning. It's also worth pointing out that per-symbol versioning info is becoming more common in upstream sources. For example, wxWidgets has an out of source scheme suitable for Linux builds but I don't see any reason we couldn't add an in-source scheme, particularly if this was desirable for Apple. On the other hand, it looks like Apple does something really odd with the wx library versions that they ship. I am almost positive we didn't ship 2.8.4 with current version 2.8.4 compatibility version 2.6.0. The major version (e.g. 2.8) is actually coded as part of the library name, the soname is that plus the first component of the libtool version (which is also incidentally part of the dylib's full name) and the remaining libtool version components (which have nothing to do with the library version) are used for the dyld versioning info with the compatibility version being the earliest release. Why they decided to do that after we got it all correct (at least as far as I'm aware) boggles my mind. It's also sort of a pain to have to find an copy the old version. So I was wondering if there is some equivalent to install_name_tool that I can use to change the versioning info. For instance, grab libiconv.dylib from either the SDK being used to build (or the system), modify the compatibility version number, and place the modified copy into a directory on the linker's -L path. As far as I know, it would be rather trivial to write such a tool and if there isn't one I'll do it. But I figured I'd ask before embarking on that. I did a quick hack version one evening several months ago http://pogma.com/misc/editlib.c (it edits the library in place, so make a copy first - better yet, make something that is not a quick hack). I suggest that you copy your libiconv, edit the headers and then edit the compatibility versions etc, then put your new headers and library at the head of your -I and -L paths (thus avoiding the need to edit the system library and header - usually not a good plan). No need to edit the headers. It's enough to just reprototype with the right availability macro after including the usual headers. And yes, I already figured out that I need to edit the version of the library. Thanks for the source. I was hoping someone had done something similar enough I could borrow it to get started. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using weak linking and other techniques with non-Apple libs
by Peter O'Gorman 25 Feb '08

25 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.9 (X11/20071115) David Elliott wrote: > In lieu of Apple changing the library to use compatibility version 5.0.0 > current version 7.0.0 (which would probably be the better thing to do) > is there some way I can do this myself? One hack I have tried is to > simply grab the /usr/lib/libiconv from the 10.4 SDK and drop it in one > of the directories on the linker's -L path. This seems to work without > problem now but I'm thinking that if we were to ever use new symbols > present only in the newer library versions, even if weak-linking to them > similar to the above, we'd be in trouble. Apple will never go back and lower the compatibility version, it would cause applications using libiconv built on Leopard to cease working (requiring version 7.0 but libiconv is 5.0). That being said, I think that you ought to file an enhancement request on this. Currently, Apple builds open source projects as designed, and uses the library versions supplied by upstream. In the case where there is only added API however (such as the libiconv version bump) it would be better if Apple were to patch the headers to include AvailabilityMacros.h and mark the added api as available in mac os x version whatever and later. There are, however, a large number of open source projects that are responsible for many of the libraries in /usr/lib, it may be too burdensome to expect Apple to inspect and patch all of them like this. Still, does not hurt to ask. > > It's also sort of a pain to have to find an copy the old version. So I > was wondering if there is some equivalent to install_name_tool that I > can use to change the versioning info. For instance, grab > libiconv.dylib from either the SDK being used to build (or the system), > modify the compatibility version number, and place the modified copy > into a directory on the linker's -L path. > > As far as I know, it would be rather trivial to write such a tool and if > there isn't one I'll do it. But I figured I'd ask before embarking on > that. > I did a quick hack version one evening several months ago http://pogma.com/misc/editlib.c (it edits the library in place, so make a copy first - better yet, make something that is not a quick hack). I suggest that you copy your libiconv, edit the headers and then edit the compatibility versions etc, then put your new headers and library at the head of your -I and -L paths (thus avoiding the need to edit the system library and header - usually not a good plan). Peter -- Peter O'Gorman http://pogma.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

Start of Volume on Mac Intel
by vishal chauhan 25 Feb '08

25 Feb '08

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: Need advice on catching thorny hang
by Brian Bechtel 25 Feb '08

25 Feb '08

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:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=biXh6ddepIadmR9t7lgZ1Qfz87ve1fx5ZQv0+HHQT3I=; b=Fhj4f2vPSwLdZRmL0pwbXFLNVe4+liK4DkhrloWmiIi+FacG3kY32fNwl2gJlCrdJZQGDnTMpzXpBEUFMD2NUjE9QIYFpfIhMsbOrX+6oZavjLU85b4d3UA63wm69ce2grcIFc7M8rfsd5SjB6dyXYc/pYQr3nDtow6ZJTtEhdU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G4JPo1/shewFMMZmZ4HwvImsTowkCwQXnOjCXcM0Dn1ZofGHY7LsSLtWfrSdqEVZQuYhMRdahmzv89DynSOOM7KXhNn4myxQo6IA2S+lFz6geO2W/8oqDyUh0PklbVKIzmVIAvMwiZF3mKWW2AriH2qMXTS2Gjj2NxTtuck2K1Y= On Sun, Feb 24, 2008 at 7:21 AM, David Hoerl <dhoerl(a)mac.com> wrote: > I have a MacBook Pro that apparently crashes, and my regular bug > reports have not resulted in anything I can do to assist Apple in > tracking down the reason. Hangs are the worst bugs, because they are so nebulous. > My computer is used mostly in a "closed lid" mode, with occasional > use in portable mode. I never seem to have problems with it in > closed-lid mode - its always a result of going to portable mode (ie I > use it untethered). > > I am using Time Machine, so before I unplug the computer I unmount > the Time Machine disk, then do a "Sleep" from the finder. > > Two events are happening fairly regularly: > > 1) When the machine gets re-plugged into all the cables needed for > closed lid mode, it never wakes up, and I have to use the power > switch to shut it down for real, then reboot it. When this happens, > the fan is going. That sounds like it could be either a panic, or a runaway process. Look for log files in the directory /Library/Logs/PanicReporter/. > 2) Last night, the machine just froze. I was in Xcode typing away > when the trackpad and keyboard went dead. I have the clock in the > menu bar show seconds, so I can see if the Window Manager is running, > but it was stopped too. The system log might be helpful; a full system profiler report includes the last portion of each log. Choose "Full Report" from the "View" menu before saving a system profile, or use the command line /usr/sbin/system_profiler -detailLevel full -xml >hoerl.spx and send the the spx file. > Apple had suggested I try to ssh into the machine, which I have, but > its non-responsive (I cannot get a login prompt). When the machine > does reboot, there is nothing in the log - no crash report, nothing > at all. Its like it never happened. You can try connecting before the panic, and doing the command tail -f /var/log/system.log to see the system log. > So, the purpose of this post: what else can I do to try and track > down what is going on? Is the some additional logging or reporting I > can enable? Assuming you have two Macs available, you can use the firewire SDK from http://developer.apple.com/sdk and the FirewireKPrintf folder contained therein. Download the Firewire SDK 26 disk image, mount it and install it. You'll have a new folder in /Developer/ called FirewireSDK26. In there you'll find Tools/FirewireKPrintf. Open the rtf file which is the readme. You'll need to modify your boot arguments with sudo nvram boot-args="debug=0x8 io=0x80" install the appropriate kext, and reboot. Attach the second mac with a firewire cable, launch fwkpfv, and get the log. That's kind of how I remember how to do it; details may vary. This will generate a large amount of power management logging which can be sent to Apple to be attached to the bug. The only other idea I can think of is to generate a core dump and send it to Apple. That's a LOT of data. Technote 2118 has details; see <http://developer.apple.com/technotes/tn2004/tn2118.html> Good luck; it's a hard problem > Can I build a debug kernel and use it to catch the > problem? You can build and install a debug kernel, but without knowing more about the hang, it's difficult to imagine it would help. _______________________________________________ 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