Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?
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?
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?
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?
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
