Hi, After spending a few more hours on the problem, I finally found what was causing the panic...and more importantly for me, how to avoid it. I am still posting a bug to Apple, because as you mentioned it, this should never happen. What triggers the panic in my application is the following: my application is multi-threaded and as I mentionned, I have one thread saving data at regular intervals (using writeToFile:atomically of NSData). Another thread is triggered by a timer and is checking the amount of free disk space every second using : NSFileManager *fm = [NSFileManager defaultManager]; NSDictionary *fsattrs = [fm fileSystemAttributesAtPath:@"/"]; If the data being written is big enough so that it takes a few seconds to write, I can see that the call to writeToFile:atomically:(NSData) never returns. The thread performing the write operation has become uninterruptible and stays so until the system crash. I assume it is the call to [fm fileSystemAttributesAtPath:@"/"] that interferes with the write operation and causes the write operation to fail. The workaround for me is simply to avoid doing that call to fileSystemAttributesAtPath when the program is in the middle of a save operation. I assume that knowledgeable readers of that list will know why the observed thread behavior causes the system to panic. Thanks for the replies. Matthieu On 18 Jun 2004, at 21:32, Shawn Erickson wrote: On Jun 18, 2004, at 10:46 AM, Matthieu Kopp wrote: Hi, I am posting this question to both groups as it involves both drivers and kernel knowledge. I am working on a piece of COCOA code that writes data to disk at regular intervals. The data is written using a NSData object using the writeToFile:atomically method.The size of the file produced during the write operation varies between 100Kb and 5Mb and I typically produce 5 files/minute. Very often, I am getting a kernel panic during the write operation. It can happen after just 2 minutes of operation or at a later stage, say after an hour. It is much easier to get the panic when the writing is performed by a thread that is not the main thread. (I typically do the writing using a ThreadWorker). My test system is a Powerbook G4 (550Mhz) with 1.9Gb of free disk space. I *cannot* reproduce this problem on my G5 2x2Ghz. A sample panic log is shown below. As a side note regardless of what you do in your application you should not be able to trigger a kernel panic, especially if using standard IO services like you are, no matter how hard you try. File a bug report with the panic information, etc. ... <http://developer.apple.com/bugreporter/index.html> -Shawn _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.