Sco Openserver 5.0.X - Streams leak - Fix

[Mark Stubbs]

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.