On Tuesday, August 14, 2012 02:51:19 pm Scott Classen wrote:
> 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)
^^^^^^^^^^^^^^
That line appears to indicate that there was no error when run under valgrind.
Is that true, or did you get the same system error as before?
If there is a memory access/free error that valgrind doesn't notice, then your
problem is out of my range of expertise.
sorry,
Ethan
> ==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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
--
Ethan A Merritt
Biomolecular Structure Center, K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742
