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 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?
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
Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Folks, 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) > > $ geeqie --version > Geeqie 1.2 That explains somehow. First I really believe there are some troubles in libgtk and libglib in stable debian. Then that version is somehow older and there was some fixes in unstable. I'll try to get the current 1.2.2 or even 1.2.3 back to stable. > Unfortunately version 1.2.2 from testing and unstable has some dependencies > (Upgraded libraries) that I can't fulfill at the moment. Then, build it from source. On unstable: apt-get source geeqie Copy that stuff to stable and then on stable as root: apt-get build-dep geeqie And as normal user in the copied directory: debuild After that you should have a nice .deb package that you can install. > 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 "select all "1"" and > then "delete", > the propability of things going bad is even higher. We might need to dig deeper into that. But first it has to be ruled out that: - - No problems with libs are shown (What I suspect as I seen some problems like that too in the past) - - Bug is still in the most current version > I don't use the gnome trash, by the way. :-) Good to hear. ;-) However, geeqie is using libgtk and glib. > Can I recompile the latest debian package (1.2.2) in my current environment > or do I need to upgrade libs for that? Yes. See above. That should work. Am Di den 8. Mär 2016 um 18:26 schrieb 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. That's exactly what I seen too in the past. But the problem is gone now (on debian unstable). So I really have some guess that it is the libraries. You can try to run it under valgrind. But expect it to be hell slow. 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 iQGcBAEBCgAGBQJW3xV0AAoJEKZ8CrGAGfas+UwMALlrX2vn7oeHqQuiaVxWcgIK FaNzdX/vSwxjKTHXV9SEw6UPeG+BkF0k1rAdJuszHQzY85H66CBc8dwO9Aw9Visi 1YyfpvLmxykG9RkGieTWTfTSlyLbzdaDbpzaARWBgZZcllbaauR84v3Fn4ms8bOg QeGsmtnVFk3a+4rRD6c6zHNMxcpCl23F8sPjtKuhgLqOvj6xTd5CioBIs/jP6TXR h348uQ2hxregB8USR2BLLiPgFQkxz5Wih3jr+01rlEcKHjNgbZfFMGcU1lI9bIvZ YEUyYh3/exjY25RYc2RoiKQD7b9n088FRxsTtSuwvKVQNpji+VqLOYStwSebhhR2 2N1RWTM4wXY6dQYqUNErksHOLPPk5nCOko3iKRunYe84fdBEZ0bkw6yTi4FfDob5 j6aWrjADewgNWMyX82DJyg18YGD7cVG3FMypYxUb4pYklkJcAO25wPjvhvzXHj1r fxz4DFsp+T3s2p+lg8OX7JP8aN7fxYShWVVBVyLOPQ== =fNji -END PGP SIGNATURE- -- 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?
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?
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 "
