Sco Openserver 5.0.X - Streams leak - Fix
Mark Stubbs
mark_stubbs at hotmail.com
Sun Apr 6 09:33:50 GMT 2003
I've copied this from my posts to comp.unix.sco.misc
It's a nasty hack, but solves my problem. Maybe someone can
use the information to tidy this up. It's actually a Sco problem which they
have
apparently fixed in 5.0.7, but there are many earlier version out there.
>The problem is with the Sco Openserver Kernel, but as it's only debug
>info that uses the result of the call in samba, I concur with Bela
>that it's safe to remove.
>Bela's suggestion was:-
> if (DEBUGLEVEL < 5) return; /* not the right variable name... */
"DEBUGLEVEL" is the correct name.
>The leak happens when Samba asks the kernel about socket options that
>are not supported. The loop calls getsockopt() with every possible
>option (including some that the kernel doesn't support), and then
>discards the data without using it at all, unless the debug level is
>high.
Who is responsible to release the memory allocated by getsockopt?
>What I actually did was:-
>==================================
in source\lib\util_sock.c
>static void print_socket_options(int s)
>{
> int value;
> socklen_t vlen = 4;
> smb_socket_option *p = &socket_options[0];
>/* MARK commented out this bit - 03-04-2003 */
>/*
> for (; p->name != NULL; p++) {
> if (getsockopt(s, p->level, p->option, (void *)&value, &vlen)== -1)
> { DEBUG(5,("Could not test socket option %s.\n",p->name));
> } else {
> DEBUG(5,("socket option %s = %d\n",p->name,value));
> }
> }
>*/
Bela's suggestion to ask first for debug level is much better
as it will save system time on every OS.
(Of the use a "magic number" like that "5" is bad coding practice...)
I think the guys on the samba mailing list will be happy
to implement this hack, but:
samba 2.8 is "closed", they are working on 3.0
that problems occurs only on SCO.
So a patch for SCO will be the only thing?
But:
That fixes the memory leakage with samba.
Will there be a patch for 5.0.6a which fixes the actual
leakage in the kernel forgetting to free the memory?
There may be other applications where that problem is not so
obvious.
>Thanks for the help.
Thanks for posting the solution.
More information about the samba-technical
mailing list