site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi Terry, Let me explain my problem a bit in detail. This is consistently happening ? - (2) Except for auditing, events can be dropped "safely" -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Sep 21, 2007, at 6:23 AM, JanakiRam wrote: I'm doing maintenance of the Mac application which has User Daemon for reporting activity and kernel extension for handling low level file operations. This application is Creating memory in chunks ( abt 3 MB) and manages memory itself . Its also using Mach semaphores. i) Once my application is started ( kext as well ) , the system hangs on PowerBook G4 , But on iMac G5 its works without any problem. The above mentioned problem is only appearing on PowerBook G4 but not on iMac G5. System gets hanging once i launch my application. I don't have any clue on this. Can you provide some pointers on the reasons of such kind of behaviour ? . Do you think this problem is related to memory management ?. I've verified your suggestion i.e autovectorization. In my kext XCode project this option is OFF. Still my machine is hanging. Please help me to solve the above mentioned problem. The reason I talked about memory issues at all is that you brought up the issue of a MALLOC failure. But that was before this information about your design. Given this information, it could just as easily be that the MALLOC failure happened because you ran it out of memory trying to buffer up lists of events to hand off to user space before freeing the memory, and user space is not servicing the requests as fast as they are being generated. User space might not service the events for a variety of reasons, including, but not limited to, insufficient CPU power, insufficient scheduling of the user space component, insufficient priority of the user space component relative to the priority of other tasks on the system which are generating events, etc.. I expect that the problem is a deadly embrace deadlock, unless you are going out of your way to make your application and every daemon talked to by every framework that it's linked against are immune from having their file activity intermediated by the KEXT. Deadly embrace would occur if it has been asked whether or not it should allow itself to access a file, and needs to access the file in order to answer the question about itself. If you are not hitting a deadly embrace, and it is in fact a starvation deadlock, it probably happens on the G4 because it has less CPU power, and if you load the G5 up enough, it will likely happen there too. This sounds very like the announced FSEvents interface or the Common Criteria Auditing subsystem, r the implementation of "memberd" (the user space group membership resolver). In all of these cases, we've had to be incredibly careful to ensure that: (1) Our components are immune from introspection (they don't look at their own traffic) (a) for FSEvents, this means aggregating events upward in the FS hierarchy and changing them from "this changed" to "you need to look in all subdirectories and files of this directory to see what changed" (b) for memberd, the operation is either blocked until a timeout (after which it is denied), or it's just immediately denied. (3) Events can also be "preordianed", by caching the information you need to answer the questions about critical path requests. (4) For auditing, if some condition prevents auditing (e.g. the audit log fills up, etc.), the system basically locks up until the condition is corrected (this is the right thing to do, if you need non- repudiation). Getting this sort of thing "right" depends very much on your goals for your software, and you will need to understand precisely how your software interacts with the system. This email sent to site_archiver@lists.apple.com