Help Please

[Kenichi Okuyama]

Dear Richard-san,

>>>>> "RS" == Richard Sharpe <sharpe at ns.aus.com> writes:
>> 1) You're using unix-like OS, not unix.
>> Like VxWare or Phoenix, there are several unix-like os which do
>> not support multi-task, but does support multi-thread. In this
>> kind of cases, my recommendation is
>> "Don't use Samba, at least none of current available."
>> This is because Current Samba still have extreame number of
>> memory leak, especially when you know that daemon process will
>> soon exit(). They simply throw cleanups to OS.
>> Fixing this will become extreame works. Sometimes making Yet
>> Another Smaller Samba might be of less work.
RS> I did some work on an embedded SMB server a while ago, and used the
RS> PTHREADS, but any threadding package would do the job.

That's because most of the memory leak is being held when you lack
memory. The code still have numbers of memory leak when you loose
one. And each loosing size is not so large.

So, as long as you have environments that is unix, which means you
have large memory spaces, you'll not find memory leak easily.
You might need to run them for 1 month, to letting them start
avalanch.


RS> However, I agree. Memory leaks were hard. I ended up with a DEBUG package
RS> unlike the Samba stuff, where I could switch on different levels of debug
RS> for different areas of the code. I have seen an even better DEBUG package
RS> elsewhere ... But that helped track down memory leaks ...

But even with those tools, you'll only find half of memory leaks.
Memory leaks occur on exceptional cases, and it's called exceptional
because things are rare to happen.

I'd rather recommend to walk through the code if you really wish to
get rid of them. And to make walk through easier, I recommend to
brush them up from bases.
# For example... currently we have pointer to recieve buffer as
# global variable. And we sometimes pass that pointer to function,
# loose them, and pick them up again from global variables.
# As long as we keep such structure, we can never get rid of memory
# leaks.
---- 
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
               @Samba Users Group in Japan