valgrind is usually pretty good at indentifying the cause of problems
like this. Here are the results of a valgrind run for this issue:
[jmongan.chemcca24 antechamber]$ valgrind --tool=memcheck
--leak-check=yes ./parmchk -i /tmp/FRH.mol2 -f mol2-o foo
==4092== Memcheck, a memory error detector for x86-linux.
==4092== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==4092== Using valgrind-2.2.0, a program supervision framework for
x86-linux.
==4092== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==4092== For more details, rerun with: -v
==4092==
==4092== Invalid read of size 1
==4092== at 0x1B904322: strcpy (mac_replace_strmem.c:198)
==4092== by 0x806198B: chk_improper (parmchk.c:3259)
==4092== by 0x8062D6A: main (parmchk.c:3662)
==4092== Address 0x1B920F59 is not stack'd, malloc'd or (recently) free'd
==4092==
==4092== Process terminating with default action of signal 11 (SIGSEGV)
==4092== Access not within mapped region at address 0x1B920F59
==4092== at 0x1B904322: strcpy (mac_replace_strmem.c:198)
==4092== by 0x806198B: chk_improper (parmchk.c:3259)
==4092== by 0x8062D6A: main (parmchk.c:3662)
==4092==
==4092== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 1)
==4092== malloc/free: in use at exit: 377748 bytes in 18 blocks.
==4092== malloc/free: 21 allocs, 3 frees, 378804 bytes allocated.
==4092== For counts of detected errors, rerun with: -v
==4092== searching for pointers to 18 not-freed blocks.
==4092== checked 1982788 bytes.
==4092==
==4092== LEAK SUMMARY:
==4092== definitely lost: 0 bytes in 0 blocks.
==4092== possibly lost: 0 bytes in 0 blocks.
==4092== still reachable: 377748 bytes in 18 blocks.
==4092== suppressed: 0 bytes in 0 blocks.
==4092== Reachable blocks (those to which a pointer was found) are not
shown.
==4092== To see them, rerun with: --show-reachable=yes
Segmentation fault
Here's the section of code in question, with line 3259 indicated by !!!:
void chk_improper(void)
{
int i, j;
int suc;
char tmpc1[5], tmpc2[5], tmpc3[5], tmpc4[5];
char name1[5], name2[5], name3[5], name4[5];
fprintf(fpout, "\n%s\n", "IMPROPER");
for (i = 0; i < impropernum; i++) {
suc = 0;
strcpy(tmpc1, atom[improper[i].atid1].ambername);
strcpy(tmpc2, atom[improper[i].atid2].ambername);
strcpy(tmpc3, atom[improper[i].atid3].ambername);
!!! strcpy(tmpc4, atom[improper[i].atid4].ambername);
So it appears there's a problem with the .ambername pointer of the
fourth atom of one of the impropers. Probably either a bad pointer or a
missing \0 terminator in the string.
I'll leave it to others who understand this code to track down where
exactly it is that the atom[] array is getting corrupted, but hopefully
this will focus the search a bit.
Cheers,
John
David A. Case wrote:
> The parmchk problem may be harder to crack than I first thought....
>
> The example (FRH.mol2) works with gcc 4.0.2 on x86, and with gcc 3.4.4
> on x64_64 (both linux). Also works with icc version 9.0 on x86_64.
> Adding "-Wall" to gcc compilation gives no hints. "lint" gives lots of
> messages (as usual) which might lead to some clues.
>
> It (parmchk) segfaults (even with -g -O0 compilation) on gcc 3.4.4 on cygwin.
> However, this same executable when run under gdb completes with the correct
> answer. So, even going in with fprintf() may not really work...I'll try
> if/when I have some time, but I am travelling now.
>
> David: can you give us the result of "gcc --version"? I remember you saying
> that you were using FC4, but we may need to pin this down further.
>
> ...dac
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Nov 30 2005 - 21:53:01 PST
