Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-03-08 Thread John Stoffel

Hartmut> You are certainly right that I can (and maybe should) run a
Hartmut> real 64bit kernel. I am already in the process of doing it,
Hartmut> but there are so many programs to install and configure that
Hartmut> it is going to take some time until my 64bit jessie can take
Hartmut> over.

I don't think you need to do anything more than install the 64bit
kernel from the current distro and let apt-get install all the
dependencies for you.  Thne you just reboot and it should (knock on
wood!) work. 

Hartmut> But I had the same problem with 4G of RAM.  So this is not a
Hartmut> "more than 4GBytes of RAM is too much on a 32bit kernel" only
Hartmut> problem.

Sure, but I think the problem is that geeqie (or the libraries it
depends on) are too aggresive with memory usage, which causes problems
when you exhaust all the memory it can access.

When running a 32bit program, even on a 12gb machine, a process can
only access about 3gb worth of data at any one time no matter what as
I recall.  Now you can have multiple processes using lots of memory,
but I think you can only use 3gb (not 4gb, since you need to leave the
other 1gb for system libraries and such) of process memory space. And
thinking on it, it might even be limited to just 2g/2g split.  

Hartmut> I would like to understand why the system becomes unstable.
Hartmut> "Too much RAM" sounds too easy. There must be at least one
Hartmut> bug to find.

I suspect geeqie does have memory problems.  I'll have to try and see
if I can find the time to spin it up in a 32bit VM and see what
happens.  Or even on a rapsberryPi as a test.  

Hartmut> And I want to run all my tests on 64bit jessie as well.  I
Hartmut> have not seen geeqie perform well under that condition yet.

If you can get this same issue to happen under a 64bit OS, kernel and
geeqie version, then that would be interesting for sure.  And
something I could maybe even help out with testing out.

John

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-03-08 Thread Hartmut Niemann
Hi John!

You are certainly right that I can (and maybe should) run a
real 64bit kernel. I am already in the process of doing it,
but there are so many programs to install and configure
that it is going to take some time until my
64bit jessie can take over.

But I had the same problem with 4G of RAM.
So this is not a "more than 4GBytes of RAM is too much on a 32bit 
kernel" only problem.

I would like to understand why the system becomes unstable.
"Too much RAM" sounds too easy. There must be at least
one bug to find.

And I want to run all my tests on 64bit jessie as well.
I have not seen geeqie perform well under that condition yet.

Hartmut


Am 08.03.2016 um 22:26 schrieb John Stoffel:
> Klaus> Am Mo den  7. Mär 2016 um 23:12 schrieb Hartmut Niemann:
>>> $ cat /proc/version
>>> Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version
>>> 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)
> I really think this is your problem in alot of ways.  You have an i686
> kernel (32bit) with the PAE extensions installed because you have 12gb
> of RAM in the system.  Why aren't you running a x86_64 (64bit) kernel
> and userland?  You can certainly install the 32bit libraries as well
> if you need them for an application.
>
> But moving to a pure 64bit kernel (can you send the output of cat
> /proc/cpuinfo?)  with a mixed 64bit/32bit userland (if needed) you'll
> get a much bigger address space.
>
> Now I can certainly see how geeqie, or possibly the toolkit and
> libraries, might not handle large amounts of highmem properly on a
> 32bit system using PAE.
>
> In my mind, it's just not worth the hassle.  How hard would it be to
> install a 64bit kernel on this system?
>
> John
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Geeqie-devel mailing list
> Geeqie-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geeqie-devel


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-03-08 Thread Ian Munsie
I hit memory issues as well (all versions I've tried - 1.2 from source,
Debian's version, even going back to 1.0 still hits it), but it's only
virtual memory usage - resident memory stays contained. On 32bit geeqie
will start behaving badly once it hits 4GB virtual memory (which is easy to
hit scrolling through a directory with a couple of hundred .cr2 images),
first auto rotation stops working then an image or two later it stops
loading further images. It does not crash. The 64bit version doesn't
eliminate the problem, but has enough virtual address space that it is not
practical to hit.

-Ian

-- 
http://darkstarsword.net
http://darkstarshout.blogspot.com
http://github.com/DarkStarSword
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-03-08 Thread Hartmut Niemann

Hi!

John, you asked about versions:

$ cat /proc/version
Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc 
version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 
(2016-01-17)


$ geeqie --version
Geeqie 1.2

$ ldd `which geeqie`
linux-gate.so.1 (0xb77d5000)
libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 
(0xb72b8000)
libgdk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0 
(0xb71f7000)
libpangocairo-1.0.so.0 => 
/usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0 (0xb71e8000)

libatk-1.0.so.0 => /usr/lib/i386-linux-gnu/libatk-1.0.so.0 (0xb71c)
libcairo.so.2 => /usr/lib/i386-linux-gnu/libcairo.so.2 (0xb7077000)
libgdk_pixbuf-2.0.so.0 => 
/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 (0xb704f000)

libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb6e99000)
libpangoft2-1.0.so.0 => 
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0 (0xb6e8)
libpango-1.0.so.0 => /usr/lib/i386-linux-gnu/libpango-1.0.so.0 
(0xb6e2e000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 
(0xb6dd)

libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb6ca8000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 
(0xb6c66000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 
(0xb6bb3000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 
(0xb6bb)

libjpeg.so.62 => /usr/lib/i386-linux-gnu/libjpeg.so.62 (0xb6b51000)
libtiff.so.5 => /usr/lib/i386-linux-gnu/libtiff.so.5 (0xb6ad4000)
liblcms2.so.2 => /usr/lib/i386-linux-gnu/liblcms2.so.2 (0xb6a72000)
libexiv2.so.13 => /usr/lib/i386-linux-gnu/libexiv2.so.13 (0xb67e6000)
liblua5.1.so.0 => /usr/lib/i386-linux-gnu/liblua5.1.so.0 (0xb67b4000)
liblirc_client.so.0 => /usr/lib/liblirc_client.so.0 (0xb67ad000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb66bb000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb6675000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6657000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 
(0xb663b000)

libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb648e000)
libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 
(0xb6489000)

libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb6337000)
libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 
(0xb6332000)

libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xb632e000)
libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xb6327000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb631b000)
libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 
(0xb6317000)

libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xb6303000)
libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xb62f7000)
libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xb62eb000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb62d6000)
libpixman-1.so.0 => /usr/lib/i386-linux-gnu/libpixman-1.so.0 
(0xb621d000)

libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb61ef000)
libxcb-shm.so.0 => /usr/lib/i386-linux-gnu/libxcb-shm.so.0 (0xb61eb000)
libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 
(0xb61e)

libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb61ba000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb619d000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb6193000)
libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb616b000)
libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 
(0xb6154000)
libharfbuzz.so.0 => /usr/lib/i386-linux-gnu/libharfbuzz.so.0 
(0xb60f7000)

libthai.so.0 => /usr/lib/i386-linux-gnu/libthai.so.0 (0xb60ed000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb60e4000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6072000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb6049000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb602)
libjbig.so.0 => /usr/lib/i386-linux-gnu/libjbig.so.0 (0xb6011000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb600b000)
/lib/ld-linux.so.2 (0xb77d8000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6007000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb6001000)
libgraphite2.so.3 => /usr/lib/i386-linux-gnu/libgraphite2.so.3 
(0xb5fda000)

libdatrie.so.1 => /usr/lib/i386-linux-gnu/libdatrie.so.1 (0xb5fd)

Unfortunately version 1.2.2 from testing and unstable has some dependencies
(Upgraded libraries) that I can't fulfill at the moment.


My normal workflow is that I mark some pictures as "1" and then "select 
all "1""

and "delete".
I observed that usually the problems start when I deleted a bunch of files.
I am not sure, but if I select "show only "1"" and then 

Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-02-26 Thread John Stoffel

Klaus> I seen that behaviour before but not recently (And I also have
Klaus> dirs with high amount of files).

I just did some testing last night on my Mint 17.3 system as well,
using geeqie 1:1.1-8 and I didn't see major growth of the library,
even with lots of thumbnails.

Klaus> I suspect that bug to have to do with some library problem. (I
Klaus> use debian sid.)

I'm interested in hearing about the 32bit vs 64bit issues, since I
suspect that might be the root cause here.  

Klaus> Am Fr den 26. Feb 2016 um  1:36 schrieb John Stoffel:
>> git://geeqie.git.sourceforge.net/gitroot/geeqie/geeqie
>> 
>> and building it and letting us know what happens?

Klaus> Never use that repository. We migrated away from sourceforge
Klaus> long ago.  The last commit on that repository is from end of
Klaus> 2010(!). Sourceforge is a company that is not trustworthy as
Klaus> they bundles malware with downloads. (Although the company has
Klaus> changed since then but the trust is sustainable destroyed.)

Oops!  I just had my own repository sitting around looked at the
origin.  I've since blown it away and re-cloned.  Thanks!  Too bad we
can't get into SourceForge and nuke that repository...

Klaus> The current repository is git://www.geeqie.org/geeqie.git

Klaus> I did some bugfixing recently in master branch but that does
Klaus> not address this particular issue.

Klaus> Current version in debian is 1.2.2-2 which met upstream and
Klaus> there is already one bugfix commit on release branch ahead
Klaus> waiting for the next release.

Nice!  

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-02-26 Thread Klaus Ethgen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Do den 25. Feb 2016 um 23:25 schrieb Hartmut Niemann:
> My geeqie consumes HUGE amounts of main memory and every other day 
> crashes the X server.
> 
> I mean: I flip through two or three directories of 100 photos each and I 
> can watch
> the (buffers?) memory rise in the GByte range.
> After some usage, the thumbnail view starts having problems, showing 
> about half of the thumbnails,
> the rest is just white
> (showing different thumbnails when I choose a different photo and the 
> thumbnail view is redrawn).
> 
> When these problems start and I continue using it, sometimes it is 
> aborted with some X error message
> (next time I copy it to a file, I promise), sometimes X crashes and I am 
> back to the login screen.

I seen that behaviour before but not recently (And I also have dirs with
high amount of files).

I suspect that bug to have to do with some library problem. (I use
debian sid.)

Am Fr den 26. Feb 2016 um  1:36 schrieb John Stoffel:
> git://geeqie.git.sourceforge.net/gitroot/geeqie/geeqie
> 
> and building it and letting us know what happens?

Never use that repository. We migrated away from sourceforge long ago.
The last commit on that repository is from end of 2010(!). Sourceforge
is a company that is not trustworthy as they bundles malware with
downloads. (Although the company has changed since then but the trust is
sustainable destroyed.)

The current repository is git://www.geeqie.org/geeqie.git

I did some bugfixing recently in master branch but that does not address
this particular issue.

Current version in debian is 1.2.2-2 which met upstream and there is
already one bugfix commit on release branch ahead waiting for the next
release.

Regards
   Klaus
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCgAGBQJW0DgVAAoJEKZ8CrGAGfaswbEL/iMRyMWAZZ29zyqzj3d9sebg
V4GRzWh6IUSwKxaGNCizG6YuDO/4pZjGA/MLwU06ehwgViszG8kp2XOPQkNq4rqj
RwXjhAXf0k+J13uEXB2qT/oInzBUsDnpPlp0tqt9ietm+ByLFDL5lIAxdUVz+JjK
HBSzDvAtXU1qJeVIV2q7SqmZg47LJPnWyOAYPFn7u6adquHjDnizBty/K1frCX8P
m/JOEzLNIU3RWWL/otI2Cd5/HU7m/Z4gByy5XQcsNhf0f+PepknotgIxXJ2MQY39
fHz2sOaXxLNAFWqYtQr4AWh4YzsWYurfQ5864At48tkc6wbn74WkwKKmL+Whtwuc
RDOqyku4VWRCY8utCJytUXww3xW22vfPjrmGMWhDdfY0BJRGD9OZpKmTll1SNCRE
zwGxVJpFL4pTRmYb88X11out3sCbF/Ifw0McHbwTYE3A2cAPPcF8JopNrXR+SYOg
djcvTg0CTcQtDEj2fm0owtGaX3mlyVJGGpBq/oBb2Q==
=2EFG
-END PGP SIGNATURE-

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-02-25 Thread John Stoffel

Hartmut> My geeqie consumes HUGE amounts of main memory and every
Hartmut> other day crashes the X server.

Can you give me details please?  cat /proc/version, geeqie --version,
etc?  

Hartmut> I mean: I flip through two or three directories of 100 photos each and 
I 
Hartmut> can watch
Hartmut> the (buffers?) memory rise in the GByte range.
Hartmut> After some usage, the thumbnail view starts having problems, showing 
Hartmut> about half of the thumbnails,
Hartmut> the rest is just white
Hartmut> (showing different thumbnails when I choose a different photo and the 
Hartmut> thumbnail view is redrawn).

Hartmut> When these problems start and I continue using it, sometimes
Hartmut> it is aborted with some X error message (next time I copy it
Hartmut> to a file, I promise), sometimes X crashes and I am back to
Hartmut> the login screen.

Hartmut> I use Debian Jessie on i86 (32bit). Since I upgraded from 4
Hartmut> GB to 12 GB of RAM, geeqie just takes even more of it :-(

You should be running 64bit mode, you're probably running out of
low-mem (under 4gb) on the system.  But again, more details would
help.

Could you try cloning the latest git from:

git://geeqie.git.sourceforge.net/gitroot/geeqie/geeqie

and building it and letting us know what happens?

Hartmut> I do not use Gnome, but LXDE, so it might be some
Hartmut> (gnome-typical) tool or configuration detail missing.  Does
Hartmut> anybody have an idea, what problem I have?

Can you send a screenshot from 'top' just before it happens?  You
could also run geeqie with --debug to see if that gives more info.

John


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel