Hi, Sven Neumann wrote:
> This may very well be a memory leak in Gimp-Perl. Have you run this in > valgrind with leak-check enabled? That should give you a good idea of > where the leak actually is. This is the valgrind report: ==31947== ==31947== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1) ==31947== malloc/free: in use at exit: 47,785 bytes in 1,684 blocks. ==31947== malloc/free: 1,246,403 allocs, 1,244,719 frees, 23,095,553 bytes allocated. ==31947== For counts of detected errors, rerun with: -v ==31947== searching for pointers to 1,684 not-freed blocks. ==31947== checked 207,552 bytes. ==31947== ==31947== 50 (16 direct, 34 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 5 ==31947== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==31947== by 0x455F4A: xmalloc (in /bin/bash) ==31947== by 0x41F103: (within /bin/bash) ==31947== by 0x421273: yyparse (in /bin/bash) ==31947== by 0x41B091: parse_command (in /bin/bash) ==31947== by 0x41B14B: read_command (in /bin/bash) ==31947== by 0x41B38D: reader_loop (in /bin/bash) ==31947== by 0x41AE08: main (in /bin/bash) ==31947== ==31947== LEAK SUMMARY: ==31947== definitely lost: 16 bytes in 1 blocks. ==31947== indirectly lost: 34 bytes in 1 blocks. ==31947== possibly lost: 0 bytes in 0 blocks. ==31947== still reachable: 47,735 bytes in 1,682 blocks. ==31947== suppressed: 0 bytes in 0 blocks. ==31947== Reachable blocks (those to which a pointer was found) are not shown. ==31947== To see them, rerun with: --show-reachable=yes This is what I obtained after the Gimp server crashed. That's it, it doesn't create the swap file after the memory allocated for it finishes. Is this a configuration problem? Andrei _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
