site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Michael, On 5.3.2007, at 19:21, Michael Smith wrote: Nope, haven't know of this. Thanks, will do! kauth_listen_scope(KAUTH_SCOPE_FILEOP, FileOpScopeListener, NULL); Not big, about 24 bytes: Tried different values, the last one 200. alloc_item if (OK) { alloc_and_fill_names if (OK) { if (limit_reached) dequeue_last enqueue_item } } I don't think it's "all right", you're just getting lucky. while true ; do ; rm -rf TEMP ; cp -R TEST TEMP ; done & /Applications/MyApp/Contents/MacOS/MyApp Thanks a very big lot. --- Ondra Čada OCSoftware: ocs@ocs.cz http://www.ocs.cz private ondra@ocs.cz http://www.ocs.cz/oc _______________________________________________ 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... Well, to pick nits, since my client wants all changed files tested.... :) I assume you are only logging FILE_CLOSE notifications with the changed bit set? Well... more or yes, yup. Them and renames, for it's possible a changed file gets renamed before processed. Also, there are a few if's to limit the number of files reported: I don't report root changes, and I don't report changes in /dev/. Thing looks like this: if (uid!=0 && !strprefix(path,"/dev/")) if (action==KAUTH_FILEOP_CLOSE && ((int)arg2 & KAUTH_FILEOP_CLOSE_MODIFIED)) { printf("C uid=%ld, path=%s\n",uid,path); add_file_change(path,NULL,uid); if (connected) tl_send_done_log_info_to_clients(); } else if (action==KAUTH_FILEOP_RENAME) { printf("R uid=%ld, path=%s -> %s\n",uid,(const char*) arg0,path); add_file_change(path,(const char*)arg0,uid); if (connected) tl_send_done_log_info_to_clients(); } The OSMalloc which causes the problem (at least in the sense that if commented out, there's no crash) is in add_file_change. 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"? struct file_change { TAILQ_ENTRY(file_change) link; char *name,*oldname; // malloc'd, to be released, oldname only for RENAME unsigned long long serial; // ID of this item long pid; // caller process ID }; In "full" version of course there's much more alloc'd for the names. It, though, crashes the same when the name allocation is commented-out. How large was the limit you imposed? It might be important that, like Kauthorama does, when the limit is reached I don't cease malloc'ing; instead, for each malloc I release the oldest queued item. Essentially, the algorithm is 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. Well... of course, there is no amount of testing which could say "it's OK". Nevertheless, the application was tested for *hours* under *heavy* load -- the normal way I launch the app looks like this where TEST contains a lot of files to be reported through the KAUTH support. I do completely appreciate that this does not prove it's all right, but seems to me to be pretty strong indication... This email sent to site_archiver@lists.apple.com