site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Mar 5, 2007, at 5:09 AM, Ondra Cada wrote: kauth_listen_scope(KAUTH_SCOPE_FILEOP, FileOpScopeListener, NULL); I don't think it's "all right", you're just getting lucky. = Mike _______________________________________________ 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... since I need reports of file changes, Since you *want* reports of file changes... I assume you are only logging FILE_CLOSE notifications with the changed bit set? I've created a Kernel Authorization KEXT, based on the KauthORama standard example. My application loads the KEXT on-demand (calling kextload authorised root), the KEXT is never unloaded. The KEXT enqueues file close events, the app uses a socket to connect to the KEXT and read the queue out. Works like a charm, and never once (!) crashed... _only_ if the app is launched some time (about minute or more) after boot. On the other hand, if the app is placed amongst Login Items and automatic login is switched on, after restart the loaded KEXT crashes the kernel ("You must restart..." gray screen of death). Note please it's _only immediately after boot_ -- e.g., not having autologin on an waiting a moment before login is completely safe, just as launching manually: this never ever crashes. If it does crash, there's no information in /var/log/syslog (not even a "loaded" report) -- supposedly the crash is quick enough to prevent the log buffers to be written out. Have you set a debug= boot-arg so that you can get the actual crash/ panic message? This would be helpful. Being KauthORama-based, there's a FileOpScopeListener function there, registered using as soon as the KEXT is loaded. In the contents, I have been able to pin-point the crash to a malloc: ... fch = (struct file_change *)OSMalloc(sizeof (struct file_change), gMallocTag); // <--- if (fch == NULL) { printf("malloc error occurred \n"); lostfiles++; } else { // this code is completely commented out now, normally would store fch to queue } ... This moment, the returned value is never used, not even printed out (therefore it leaks, but the crash did occur before, when there was a length limit for the queue, too; see also (*)). How large is your "struct file_change"? How large was the limit you imposed? Still, the KEXT does crash (there's no "malloc error occurred" in the system log, but whether it's not printed out or whether it just does not make it from log buffer to log file is anybody's guess: if I add another log before the malloc, it's not there either). You can't expect a message printed mere microseconds before a crash to make it into a logfile; kernel log messages are necessarily trickled slowly out to the logfile, but they are printed much more rapidly on the console. If I ensure the malloc starts to be used about 60 seconds or more after boot -- be it by including a delay into the code, or launching the app manually (or just switching off 'auto login' and waiting a minute at the login panel), its all right and never crashes. (Not even with those leaks! I had it running for half an hour, no crash, no "malloc error" either--presumably the kernel can swap unneeded memory out (*)). No, it does not. There's a great deal of filesystem activity during startup; you're just seeing how your implementation breaks under load. This email sent to site_archiver@lists.apple.com