Re: Bug or normal behavior?

[Felix Riemann <friemann gnome org>]

So, I had another look at it (sorry for the delay) with Valgrind's
massif and eog uses actually less RAM (or at least heap space).
Depending on which plugins you load an empty eog seems to need 5-15 MB
heap. Loading one of your image adds ~40MB which is pretty much exactly
what the uncompressed image data needs.

Simple calculation: Multiply Width*Height with 3 or 4 depending on the
alpha channel and you get the number of bytes your image needs. For your
image that would be 4608*3072*3 which is ~ 40.5MB. However there is a
short moment where another 54MB are required when the image is converted
to ARGB32 (eog gets the image data either in RGB or RGBA format) for
libcairo.

Also the final scaled bitmap is likely taking up some space in the X
server as well which might be the reason it's shot down instead of eog.
Could be also just a simple malloc() call failing which is causing the
abort then due to the OOM situation.

I am not sure yet what Firefox does to reduce the memory footprint (or
if it really does so) as running it with Valgrind is not cool. Then
there's Shotwell whose behaviour is a bit odd, but it generally seems to
load the image in the size it needs it for. That saves some memory, but
it seems to load the the full size image from time to time if you play
around with the window, so it can cause similar spikes as eog.

Yet, there's likely room for improvement. For example the latest
libjpeg-turbo has support for decoding directly to ARGB which could help
avoiding that format conversion spike.

Regards,

Felix

Am Mittwoch, den 22.02.2012, 09:10 +0800 schrieb chen huacai:
> Thanks. but I still have some doubts:
> 1, I think one image consumes 40M memory is a little strange
> (comparing with firefox or other image viewer).
> 2, My PC has 1 GB memory, 6~8 images can trigger the OOM handler, but
> kernel kill Xorg, not eog...
> 
> On Wed, Feb 22, 2012 at 1:06 AM, Felix Riemann <friemann gnome org> wrote:
> > On Tue, 2012-02-21 at 08:50 +0800, chen huacai wrote:
> >> Hi, all
> >
> > Hi,
> >
> >> I found when I view a 4M jpg file with eog-3.2.2, it consumes more
> >> than 100M memory (memory information is obtained with Alt+SysRq+M).
> >> But everything is OK if I use firefox to view them. So, I want to know
> >> whether this behavior is normal, or there is a bug in eog? It cause my
> >> PC crashes when I view several images together...
> >>
> >> Below are files for testing, I use Arch Linux with kernel 3.2.5.
> >> http://dev.lemote.com/filebox.cgi?p=download&f=DSC_1660.JPG
> >> http://dev.lemote.com/filebox.cgi?p=download&f=DSC_1670.JPG
> >
> > well, if you compare an empty eog with an eog that has your image loaded
> > your numbers can be called "expected" considering that the uncompressed
> > image data of one your pictures alone adds around 40M to the memory
> > footprint. What's interesting though is that the empty eog instance
> > already takes around 50M (measured using top). That could be worth an
> > investigation. Also note that switching images causes a short spike in
> > memory usage as there's is a (really) short moment where both
> > uncompressed images require memory.
> >
> > I wonder how this can crash your PC though. Even if it doesn't have a
> > lot of memory, I always expected that eog would be aborted by the
> > kernel's out of memory handler.
> >
> >>
> >> Best regards,
> >> Huacai Chen
> >
> > Regards,
> >
> > Felix
> >
> 
> 
>