At least 1 thing that you are missing is the granularity of the memory
allocation scheme. From the OS perspective, if you ask for 80 bytes, this may
come from memory allready allocated to you. However your app may not have any
free memory, so the OS will allocate you a page of memory. A page may be, say
4K. So for the next ~50 allocations of 80 bytes you will not be getting anymore
memory from the OS, simply using what you have already been given. This
probably explains why you don't see a leak for n <= 17. This is why the leak
tests typically loop through 10,000 iterations, to try to average out some of
the granularity.
> Just tried to look for the '80 Byte' leak per PanedW creation/deletions
> I can see for test/Xm/panedw/test9
> It turned out that there is no simple '80 Byte' leak, but there
> is a more complex dependency ...
> At least on one machine (this is all on alpha/linux/gcc) I got not even
> the curve one might expect:
>
> leak(number) = constant_class + constant_widget * number
>
> where constant_class is some number which is independent of the
> number of calls. It turned out that I roughly get this curve but
>
> - the leak does not exist for n <= 17
> no explanation ...
>
> - somewhere near n=130 I got another maximum
> even harder to explain than the previous result ...
>
> Optimization level for libXm and test9 was supposed to be -O1,
> perhaps I should try again with -O0.
>
> --
> Alexander Mai
> [EMAIL PROTECTED]
>
>
