> Mike Galbraith had the wisdom to write:
> MG> According to memleak, there's a leak at accept.c:99. Sorry for
> MG> extreme brevity, but my connection drops in a few seconds.
>
> Are you sure there are no connections active when memleak
> reports this? (I have to try memleak myself, does anybody
> have a pointer/URL to it?)
False alarm.. turns out that they're just much more persistent than
anything I'd seen before. I waited for all connections to terminate
and deactivated khttpd prior to checking, but for some reason, some
allocations hung around until I put memory stress on the machine. (??)
After 5 million packets, it was 30 allocations.
Memleak does all of it's work from under the locks of the allocators,
so it shouldn't be able to miss anything. Pretty strange.
Memleak is in ikd. I can send you a functional ikd+kdb for 2.3.15-pre3
(~100k gzipped) if you'd like. (trying to figure out how to put
semaphore lockup detection back together in 2.3.15-released tree)
If you do want to check it out, don't allow removal of modules unless
you know that all allocations made from the module should have had
time to have been freed. Memleak says OOPS if there are any unfreed
allocations from modules left around after the module is unloaded.
(not a bug, a feature!.. just one that wants some housebreaking:)
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/