site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hello all, kauth_listen_scope(KAUTH_SCOPE_FILEOP, FileOpScopeListener, NULL); _______________________________________________ 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, 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. 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 (*)). 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). If I comment out the malloc, the KEXT never crashes. If I limit the number of mallocs, the KEXT starts crashing in a non-deterministic way (!) in low hundreds. 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 (*)). At the moment, it just seems that some time after boot the kernel is in a delicate state which causes malloc to crash (instead of just harmlessly returning NULL) :-O ?!? I am outta ideas :( Any hint what the heck could be the culprit and how to cure it extremely appreciated... --- Ondra Čada OCSoftware: ocs@ocs.cz http://www.ocs.cz private ondra@ocs.cz http://www.ocs.cz/oc This email sent to site_archiver@lists.apple.com