Re[2]: [Dazuko-help] about memory leak of Dazuko (2.2.0.2)

[takashi.osaka.tb]

Thanks a lots for your reply to my questions, John.
It is much helpful for me.
I have to examin more.
And when I'll need more information, I'll ask you again.

Thank you.

T.Osaka

>address@hidden wrote:
>> Could you please show me about details of these fixings? 
>> 
>> 2.3.2-pre2
>> - fix name-cache leak for Linux 2.2, 2.4, and 2.6+syscall
>>   (what is name-cache? when is name-cache leak happen? etc)
>
>Upon closer examination of the problem, it is not related to the name
>cache. The memory leak is related to filenames, which is probably why
>the association to the name-cache was automatically made.
>
>Nonetheless, it was a memory leak. The problem was that under certain
>circumstances, memory was allocated but never freed. This situation
>occurs when a file is created in a directory that is a symbolic link.
>Example:
>
>$ cd /tmp
>$ mkdir dir1
>$ ln -s dir1 dir2
>$ touch dir2/file
>
>The "touch" command will cause a single 5-byte leak (length of "dir2").
>If the "touch" command had been:
>
>$ touch /tmp/dir2/file
>
>it would cause a single 10-byte leak (length of "/tmp/dir2").
>
>These leaks occur because the file is created in a directory that is a
>symbolic link. The leaks will begin occuring as soon as an application
>registers with Dazuko (regardless of which IncludePaths are used). If no
>applications are using Dazuko, there is no leak.
>
>These leaks exist in the Dazuko versions between (and including)
>2.1.0-pre4 and 2.3.2-pre1. The leaks are only present for Linux 2.2,
>Linux 2.4, and (if configured with --enable-syscalls) Linux 2.6.
>
>LSM-based configurations (the default for Linux 2.6), FreeBSD, and RSBAC
>systems are not affected.
>
>The patch, which fixed the problem is attached to this email. If you
>need more information, please let me know.
>
>John Ogness
>
>-- 
>Dazuko Maintainer
>