Hi Ethan,

Here are the contents of the valgrind log file after running the following 
command:

valgrind --tool=memcheck --leak-check=yes --num-callers=20 
--log-file=valgrind.log 
/programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot

Doesn't mean much to me, but perhaps you or Paul might get some clues?

Thanks,
Scott

==13497== Memcheck, a memory error detector
==13497== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==13497== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==13497== Command: /programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot
==13497== Parent PID: 12940
==13497== 
==13500== 
==13500== HEAP SUMMARY:
==13500==     in use at exit: 59,581 bytes in 1,782 blocks
==13500==   total heap usage: 2,944 allocs, 1,162 frees, 113,746 bytes allocated
==13500== 
==13500== LEAK SUMMARY:
==13500==    definitely lost: 0 bytes in 0 blocks
==13500==    indirectly lost: 0 bytes in 0 blocks
==13500==      possibly lost: 0 bytes in 0 blocks
==13500==    still reachable: 59,581 bytes in 1,782 blocks
==13500==         suppressed: 0 bytes in 0 blocks
==13500== Reachable blocks (those to which a pointer was found) are not shown.
==13500== To see them, rerun with: --leak-check=full --show-reachable=yes
==13500== 
==13500== For counts of detected and suppressed errors, rerun with: -v
==13500== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
==13497== 
==13497== HEAP SUMMARY:
==13497==     in use at exit: 70,808 bytes in 1,810 blocks
==13497==   total heap usage: 5,637 allocs, 3,827 frees, 228,367 bytes allocated
==13497== 
==13497== 16 bytes in 1 blocks are definitely lost in loss record 125 of 469
==13497==    at 0x4C26FDE: malloc (vg_replace_malloc.c:236)
==13497==    by 0x465E32: xmalloc (in /bin/bash)
==13497==    by 0x42413D: ??? (in /bin/bash)
==13497==    by 0x424EA8: yyparse (in /bin/bash)
==13497==    by 0x41D2E9: parse_command (in /bin/bash)
==13497==    by 0x46AB67: parse_string (in /bin/bash)
==13497==    by 0x41E24C: xparse_dolparen (in /bin/bash)
==13497==    by 0x44D8EC: ??? (in /bin/bash)
==13497==    by 0x44859D: ??? (in /bin/bash)
==13497==    by 0x44A2BB: ??? (in /bin/bash)
==13497==    by 0x44A451: expand_string_assignment (in /bin/bash)
==13497==    by 0x44538A: ??? (in /bin/bash)
==13497==    by 0x44572E: ??? (in /bin/bash)
==13497==    by 0x44A0F5: ??? (in /bin/bash)
==13497==    by 0x42E9CE: ??? (in /bin/bash)
==13497==    by 0x42FF42: execute_command_internal (in /bin/bash)
==13497==    by 0x430BED: execute_command (in /bin/bash)
==13497==    by 0x41D535: reader_loop (in /bin/bash)
==13497==    by 0x41CCF8: main (in /bin/bash)
==13497== 
==13497== LEAK SUMMARY:
==13497==    definitely lost: 16 bytes in 1 blocks
==13497==    indirectly lost: 0 bytes in 0 blocks
==13497==      possibly lost: 0 bytes in 0 blocks
==13497==    still reachable: 70,792 bytes in 1,809 blocks
==13497==         suppressed: 0 bytes in 0 blocks
==13497== Reachable blocks (those to which a pointer was found) are not shown.
==13497== To see them, rerun with: --leak-check=full --show-reachable=yes
==13497== 
==13497== For counts of detected and suppressed errors, rerun with: -v
==13497== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)



On Aug 14, 2012, at 2:32 PM, Ethan Merritt wrote:

> On Tuesday, August 14, 2012 01:06:46 pm you wrote:
>> Hello,
>> I just downloaded the latest coot (4322) and attempted to luanch on a new 
>> CentOS 6 machine. Coot was none too happy.
>> 
>> Here is the output.
>> 
>> I'm not sure how to turn on debugging or core dumps, but if that would be 
>> useful I can redo this.
> 
> Try running the program under valgrind.
> It will be very slow, but when it hits the problem point the valgrind log will
> tell you, or more to the point - tell the developers, where in the program
> the offending memory chunk was allocated.
> 
> The command would be something like
>  valgrind --tool=memcheck --leak-check=yes --num-callers=20 
> --log-file=valgrind.log /full/path/to/coot
> 
> Note that you need to use the full path for the coot executable.
> An alias will not work.
> 
> 
>       Ethan


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Scott Classen, Ph.D.
SIBYLS Beamline 12.3.1
sibyls.als.lbl.gov
Advanced Light Source
Lawrence Berkeley National Laboratory
1 Cyclotron Rd
MS6R2100
Berkeley, CA 94720
cell 510.206.4418
desk 510.495.2697
beamline 510.495.2134
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to