Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large pdb files lead to seg fault #6

Open
andrewsb8 opened this issue Nov 24, 2023 · 4 comments
Open

Large pdb files lead to seg fault #6

andrewsb8 opened this issue Nov 24, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@andrewsb8
Copy link
Owner

Seg fault, with no log outputs, is the result when using -i examples/Villin-Headpiece/villin-unfolded-conect.pdb as an input file. Can be a memory leak or need to test on system with more system memory.

@andrewsb8 andrewsb8 added the bug Something isn't working label Feb 15, 2024
@andrewsb8
Copy link
Owner Author

Some valgrind output indicating a stack overflow in recursivePairSearch:

Command: valgrind --show-leak-kinds=all --log-file=villin-read-log --leak-check=full --track-origins=yes ./drop -f measureDihedrals -i examples/Villin-Headpiece/villin-unfolded-conect.pdb

==10026== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==10026==    
==10026== Process terminating with default action of signal 11 (SIGSEGV)
==10026==  Access not within mapped region at address 0x1FFE801FFC
==10026== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==10026==    at 0x10CD45: recursivePairSearch (in /home/bandrews/projects/DROP/drop)
==10026==  If you believe this happened as a result of a stack
==10026==  overflow in your program's main thread (unlikely but
==10026==  possible), you can try to increase the size of the
==10026==  main thread stack using the --main-stacksize= flag.
==10026==  The main thread stack size used in this run was 8388608.

@andrewsb8
Copy link
Owner Author

Wonder if I could set recursion depth limit? Then if the program doesn't find the path just have a marker that says it's greater than x number of bonds away. This avoids a rewrite for an iterative solution or a complicated data structure to calculate a number whose value doesn't ultimately matter.

@andrewsb8
Copy link
Owner Author

Or, just turn off calculating the covalentBondMatrix calculation for modules which don't require it. For example, modules measureDihedral, setDihedral, and setDihedralList do not in principle require this calculation to be done.

identifyDihedrals still uses CONECT records so this could be changed to just detect from the ATOM listings in the pdb or other input structure file for flexibility. But, that is a different conversation/issue entirely.

@andrewsb8
Copy link
Owner Author

Have officially confirmed that the seg fault is from recursion depth from counting covalent bonds between pairs of atoms. Instead of taking a short cut, I will implement an iterative solution. It could take the following form:

for(i = 0; i < number of atoms; i++)
{
    int array[number of atoms - i];
    for(j = i + 1; j < number of atoms; j++)
    {
        found = 0
        while(found == 0)
        { search for connection in bonds struct }
    }
}

The iterative list search will probably be backtracking in style but some details will have to be ironed out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant