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: Michael Smith <email@hidden>
- Date: Mon, 5 Mar 2007 10:21:31 -0800
On Mar 5, 2007, at 5:09 AM, Ondra Cada wrote:
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
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"? 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.
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.
= Mike
_______________________________________________
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