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