On Mon, Jul 1, 2013 at 2:58 PM, johannes hanika <[email protected]> wrote:

>
>
>
> On Mon, Jul 1, 2013 at 2:57 PM, johannes hanika <[email protected]> wrote:
>
>>
>>
>>
>> On Mon, Jul 1, 2013 at 1:29 PM, Patrick Shanahan <[email protected]>wrote:
>>
>>> * johannes hanika <[email protected]> [07-01-13 04:54]:
>>> > the summary only is not really enough to tell anything from it. full
>>> text
>>> > is more useful. in this case tons of false positives in opencl and
>>> > rawspeed. some warnings about uninitialized memory being accessed,
>>> which is
>>> > probably some unclean initialization, we've had that before. most of
>>> the
>>> > time it's just a padding word to be memcpyd with the rest which has no
>>> > effect regardless of the value. nothing about memory leaks though?
>>> >
>>> > > * Patrick Shanahan <[email protected]> [06-30-13 21:18]:
>>>  [...]
>>> > > Another test failed with:
>>> > >
>>> > > ==30792== More than 10000000 total errors detected.  I'm not
>>> reporting any
>>> > > more.
>>> > > ==30792== Final error counts will be inaccurate.  Go fix your
>>> program!
>>> > > ==30792== Rerun with --error-limit=no to disable this cutoff.  Note
>>> > > ==30792== that errors may occur in your program without prior
>>> warning from
>>> > > ==30792== Valgrind, because errors are no longer being displayed.
>>> > > ==30792==
>>> > >
>>> > > full text:
>>> > >   http://wahoo.no-ip.org/~pat/darktable.mem.txt
>>>
>>> Was this not helpful?
>>>
>>> Do you need it to run again?
>>>
>>>
>> see my comments in the other mail. didn't really point to severe issues
>> in our code so far. i'll just try and waste some memory here, but i have no
>> evidence whatsoever that we're leaking significant amounts of memory so far.
>>
>>
> forgot to say, you might want to run with `darktable -d cache -d mem' to
> see where some of the memory is at.
>

this is what i get after importing just> 10k images and creating thumbnails
for quite a few of them:

[memory] max address space (vmpeak):    35934032 kB
[memory] cur address space (vmsize):    35256596 kB
[memory] max used memory   (vmhwm ):     1571548 kB
[memory] cur used memory   (vmrss ):      968060 kB

and that ^ is the number you want to be looking at, vmpeak/size are just
the address space that has more to do with libc's allocation strategy than
with our memory consumption.

[mipmap_cache] level [i0] ( 186x 150) fill 131.25/784.80 MB (16.72% in
1233/8192 buffers)
[mipmap_cache] level [i1] ( 372x 300) fill 58.33/196.18 MB (29.73% in
137/512 buffers)
[mipmap_cache] level [i2] ( 744x 600) fill 13.62/196.17 MB (6.94% in 8/128
buffers)
[mipmap_cache] level [i3] (1488x1200) fill 0.00/196.17 MB (0.00% in 0/32
buffers)

and these ^ show that there is still some room to fill in my caches, so rss
will grow a little more.

[mipmap_cache] level [f4] fill 0/2 slots (0.00% in 0/4 buffers)
[mipmap_cache] level [f5] fill 2/2 slots (100.00% in 2/4 buffers)
[mipmap_cache] level | near match | miss | stand-in | fetches | total rq
[mipmap_cache] i0    |  40.22% |  40.22% |   -nan%  |  83.28% |  99.39%
[mipmap_cache] i1    |  84.88% |  84.88% |   -nan%  |   4.04% |   0.61%
[mipmap_cache] i2    |   -nan% |   -nan% |   -nan%  |   0.00% |   0.00%
[mipmap_cache] i3    |   -nan% |   -nan% |   -nan%  |   0.00% |   0.00%
[mipmap_cache] f4    |   -nan% |   -nan% |   -nan%  |   0.00% |   0.00%
[mipmap_cache] f5    |   -nan% |   -nan% |   -nan%  |  12.69% |   0.00%



>
>
>> j.
>>
>>
>>>  --
>>> (paka)Patrick Shanahan       Plainfield, Indiana, USA      HOG #
>>> US1244711
>>> http://wahoo.no-ip.org        Photo Album:
>>> http://wahoo.no-ip.org/gallery2
>>> http://en.opensuse.org                           openSUSE Community
>>> Member
>>> Registered Linux User #207535                    @
>>> http://linuxcounter.net
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Darktable-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/darktable-users
>>>
>>
>>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users

Reply via email to