Re: [COOT] turn on core dumps [was Re: 0.7-pre-1-revision-4322 crashing on CentOS 6]
Sorry. I think there was a bug in 4322 which I believe I fixed a few hours later. Please try 4323. B On 15/08/2012 01:34, Paul Emsley wrote: On 15/08/12 00:24, Scott Classen wrote: Hi Paul, I received this message after the crash: [snip] Hi Scott, Thanks for that. There will be a fixed binary (revision r4323) available shortly. Regards, Paul. -- *** Dr. Bernhard Lohkamp Assistant Professor Div. Molecular Structural Biology Dept. of Medical Biochemistry and Biophysics (MBB) Karolinska Institutet S-17177 Stockholm Sweden phone: (+46) 08-52487651 fax: (+46) 08-327626 email: bernhard.lohk...@ki.se
Re: [COOT] turn on core dumps [was Re: 0.7-pre-1-revision-4322 crashing on CentOS 6]
On 15/08/12 00:24, Scott Classen wrote: Hi Paul, I received this message after the crash: [snip] Hi Scott, Thanks for that. There will be a fixed binary (revision r4323) available shortly. Regards, Paul.
Re: [COOT] turn on core dumps [was Re: 0.7-pre-1-revision-4322 crashing on CentOS 6]
Hi Paul, I received this message after the crash: [New Thread 13701] [Thread debugging using libthread_db enabled] Core was generated by `/programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot-real'. Program terminated with signal 6, Aborted. #0 0x2b54f07c98a5 in raise () from /lib64/libc.so.6 #0 0x2b54f07c98a5 in raise () from /lib64/libc.so.6 #1 0x2b54f07cb085 in abort () from /lib64/libc.so.6 #2 0x2b54f0806a97 in __libc_message () from /lib64/libc.so.6 #3 0x2b54f080c3c6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00544bd5 in main (argc=1, argv=0x7fff6cfb7078) at main.cc:303 smime.p7s Description: S/MIME cryptographic signature
[COOT] turn on core dumps [was Re: 0.7-pre-1-revision-4322 crashing on CentOS 6]
On 14/08/12 21:06, Scott Classen wrote: Hello, I just downloaded the latest coot (4322) and attempted to luanch on a new CentOS 6 machine. Coot was none too happy. For me too (strangely enough). Investigating now... Here is the output. I'm not sure how to turn on debugging or core dumps, for the record tcsh: $ unlimit coredumpsize bash: |$ ulimit-c unlimited| When you do that you should get the core crash catcher. Paul.
Re: [COOT] 0.7-pre-1-revision-4322 crashing on CentOS 6
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 > be
Re: [COOT] 0.7-pre-1-revision-4322 crashing on CentOS 6
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 ~ smime.p7s Description: S/MIME cryptographic signature
[COOT] 0.7-pre-1-revision-4322 crashing on CentOS 6
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. classen@samos:/home/classen 1012% /programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot COOT_PREFIX is /home/programs/coot-Linux-x86_64-centos-6-gtk2-python /programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot-real Acquiring application resources from /home/programs/coot-Linux-x86_64-centos-6-gtk2-python/share/coot/cootrc INFO:: splash_screen_pixmap_dir /home/programs/coot-Linux-x86_64-centos-6-gtk2-python/share/coot/pixmaps INFO:: Colours file: /home/programs/coot-Linux-x86_64-centos-6-gtk2-python/share/coot/colours.def loaded INFO:: Using Standard CCP4 Refmac dictionary from CLIBD_MON: /programs/ccp4-6.2.0/lib/data/monomers/ There are 125 data in /programs/ccp4-6.2.0/lib/data/monomers//list/mon_lib_list.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//a/ALA.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//a/ASP.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//a/ASN.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//c/CYS.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//g/GLN.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//g/GLY.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//g/GLU.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//p/PHE.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//h/HIS.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//i/ILE.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//l/LYS.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//l/LEU.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//m/MET.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//m/MSE.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//p/PRO.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//a/ARG.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//s/SER.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//t/THR.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//v/VAL.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//t/TRP.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//t/TYR.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//p/PO4.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//s/SO4.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//g/GOL.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//e/ETH.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//c/CIT.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//a/AR.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//c/CR.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//c/CD.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//g/GD.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//t/TD.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//a/A.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//c/C.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//g/G.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//u/U.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//d/DA.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//d/DC.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//d/DG.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//d/DT.cif There are 2 data in /programs/ccp4-6.2.0/lib/data/monomers//h/HOH.cif There are 1 data in /programs/ccp4-6.2.0/lib/data/monomers//ener_lib.cif sbase monomer dir: . sbase files not found in . Reading coordinate file: /home/programs/coot-Linux-x86_64-centos-6-gtk2-python/share/coot/standard-residues.pdb PDB file /home/programs/coot-Linux-x86_64-centos-6-gtk2-python/share/coot/standard-residues.pdb has been read. Spacegroup: P 1 Cell: 40.631 109.18 93.243 90 90 90 *** glibc detected *** /programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot-real: munmap_chunk(): invalid pointer: 0x00d53dbc *** === Backtrace: = /lib64/libc.so.6(+0x753c6)[0x2b20088753c6] /programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot-real(main+0x340)[0x544bd5] /lib64/libc.so.6(__libc_start_main+0xfd)[0x2b200881ecdd] /programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot-real[0x542aa9] === Memory map: 0040-00f67000 r-xp 00:13 17151101 /home/programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot-real 01167000-011bc000 rw-p 00b67000 00:13 17151101 /home/programs/coot-Linux-x86_64-centos-6-gtk2-python/bin/coot-real 011bc000-011d7000 rw-p 00:00 0 01504000-020a rw-p 00:00 0
