[gmx-developers] pdb2gmx segmentation fault

[Erik Lindahl]

Hi,

We just (literally, yesterday) fixed a potential problem in the XTC  
writing of uchars, which caused some residue chain identifiers to be  
corrupted in amber03. Check the latest git version and see if it  
solves this too!

Cheers,

Erik

On Jul 7, 2009, at 1:14 PM, David van der Spoel wrote:

> Ran Friedman wrote:
>> Hi,
>> I have a similar problem (on linux, tried with few PDBs, this has  
>> only 1
>> chain)
>> pdb2gmx -f ~/Proteins/PM_II/PDB/3F9Q.pdb -o prot.gro
>> ...
>> Processing chain 2 (213 atoms, 213 residues)
>> There are 213 donors and 213 acceptors
>> There are 67 hydrogen bonds
>> Segmentation fault
>> ...
>> The problem is with the waters. It seems that the program crashes in
>> hizzi.c, in set_histp
>> (lines: 223-225)
>>  for(i=0; (i<natom); ) {
>>    if (strcasecmp(*pdba->resinfo[pdba->atom[i].resind].name,"HIS") ! 
>> = 0)
>>      i++;
>> Apparently *pdba->resinfo[pdba->atom[i].resind].name is not  
>> initialised
>> and this causes the problem to die. I couldn't get further so far.
>
> It seems that there are problems in pdb2gmx due to it retaining  
> original residue numbers. In principle this is a good thing, and  
> this was much requested. However, I suspect that your resind is  
> actually larger than the number of residues (you could check this in  
> your pdb file). In other words, this feature has not been  
> implemented completely consistenly, I also found a problem in grompp  
> with a new top file the other day, where the peptide had residue  
> number 16, and the solvent had lower residue numbers. I'm not really  
> sure how to continue, the code really has to be fixed.
>
> A workaround (if this really is the issue in your case) is to run  
> the pdb files through editconf first: editconf -f in.pdb -o out.pdb  
> as this program will actually renumber atoms and residue...
>
>
>> Ran.
>> Michel Cuendet wrote:
>>> Dear David,
>>>
>>> Thanks for trying to reproduce this annoying SegFault. Yes, it works
>>> fine with the 4.0.x releases, and it seems that the problem appeared
>>> when the new residue numbering was introduced. I however need the
>>> development version of gmx, because I'm testing the CMAP
>>> implementation with charmm27.
>>>
>>> I was really optimistic when I read your reply, so I immediately
>>> downloaded the GIT version of today, compiled on the machines at  
>>> hand,
>>> and tested again with 2GUO_nowat.pdb.
>>>
>>> Alas !
>>>
>>> osx_gcc4.0.1 shared      : OK
>>> i686_gcc4.2.4 shared     : SegFault     (chain A)
>>> i686_gcc4.2.4 static     : SegFault     (chain A)
>>> em64t_gcc3.4.6 static    : SegFault     (chain B)
>>>
>>> This looks like a nasty, difficult to reproduce bug... It's  
>>> annoying,
>>> because I would need to produce topologies on a Linux machine, not  
>>> on
>>> my mac...
>>>
>>> Thanks or your help,
>>>
>>> Michel
>>>> I am now doing this using the latest git source, but it works  
>>>> fine on
>>>> my Mac.
>>>> However, with a slightly older develop code it fails. With the . 
>>>> 4.0.x
>>>> release tit works fine though.
>>>> It seems to be a temporary bug that was resolved again.
>>>>
>>>> Plz upgrade...
>>>>
>>> _______________________________________________
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>> Please don't post (un)subscribe requests to the list. Use the www
>>> interface or send it to gmx-developers-request at gromacs.org.
>>>
>
>
> -- 
> David van der Spoel, Ph.D., Professor of Biology
> Molec. Biophys. group, Dept. of Cell & Molec. Biol., Uppsala  
> University.
> Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
> spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the www  
> interface or send it to gmx-developers-request at gromacs.org.
>