Re: KEXT/KAUTH, malloc-related crash, login only?!?
Re: KEXT/KAUTH, malloc-related crash, login only?!?
- Subject: Re: KEXT/KAUTH, malloc-related crash, login only?!?
- From: Ondra Cada <email@hidden>
- Date: Mon, 5 Mar 2007 21:30:10 +0100
Michael,
On 5.3.2007, at 19:21, Michael Smith wrote:
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.
Nope, haven't know of this. Thanks, will do!
Being KauthORama-based, there's a FileOpScopeListener function
there, registered using
kauth_listen_scope(KAUTH_SCOPE_FILEOP, FileOpScopeListener, NULL);
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"?
Not big, about 24 bytes:
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?
Tried different values, the last one 200.
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
alloc_item
if (OK) {
alloc_and_fill_names
if (OK) {
if (limit_reached) dequeue_last
enqueue_item
}
}
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.
I don't think it's "all right", you're just getting lucky.
(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
while true ; do ; rm -rf TEMP ; cp -R TEST TEMP ; done &
/Applications/MyApp/Contents/MacOS/MyApp
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...
Thanks a very big lot.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden