Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000295Rosetta[All Projects] Bad Codingpublic2013-08-06 18:292017-08-21 18:06
Assigned Toamw579 
PlatformAll platformsOSAnyOS VersionAny
Product VersionAll 
Fixed in Version 
Summary0000295: core::scoring::sasa::calc_per_atom_sasa_sc divides by zero with NCAAs/Ligands
Descriptionif you call calc_per_atom_sasa_sc with normalize=true, the function normalizing_area is called. normalizing_area takes the name1 of the residuetype and uses the int value of the char to get a hardcoded value from a vector. The default value of the vector is 0.0, which means that a residue with a name1 other than one of the 20 canonical name1s will return 0.0, and divide the residue sasa by 0. The result of this in c++ is undefined and will result in a random number for the normalized sasa.

I suspect that the area lookup table was implemented as a vector for speed reasons, however the current behavior is extremely dangerous and would result in very difficult to diagnose bugs. The only reason I found it at all is because I was carefully reading for another purpose. Replacing this vector with a map, hash table, or something else would address the error.

additionally, while ligands typically have a name1 of X, this is not a requirement, and thus you cannot know that a ligand with a name1 of A is actually alanine. The failure mode of this code due to strange user input is not an error but rather a potentially subtle incorrect sasa calculation of the residue. the datastructure should almost certainly be indexed by the full name of the residuetype, as a patched residuetype can maintain the same name1 or name3 and have a very different chemical composition than the canonical AA.

TagsNo tags attached.
Application(s) Affectedanything using sasa
Command Line Usedscore_jd2
Developer Options
Fixed in SVN Versionn/a
Attached Files

- Relationships

-  Notes
delucasl (Administrator)
2013-08-06 18:34

Changing status to minor. This is only currently used in core/scoring/methods/ProQ_Energy, which uses it in such a limited case that its unlikely that the bug occurs in practice. However, future use of this code outside of the originally intended scope will be subject to the bug

- Issue History
Date Modified Username Field Change
2013-08-06 18:29 delucasl New Issue
2013-08-06 18:34 delucasl Note Added: 0000310
2013-08-06 18:34 delucasl Severity major => minor
2017-08-21 18:06 amw579 Fixed in SVN Version => n/a
2017-08-21 18:06 amw579 Status new => closed
2017-08-21 18:06 amw579 Assigned To => amw579
2017-08-21 18:06 amw579 Resolution open => suspended

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker