Sco Openserver 5.0.X - Streams leak - Fix

Mark Stubbs mark_stubbs at
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
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

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?

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

>Thanks for the help.

Thanks for posting the solution.

More information about the samba-technical mailing list