Running snugdock was crashed by “segmentation fault”

[Anonymous]

Hello everyone,

When using the following command to run snugdock in my centos 7 system:

 snugdock.linuxgccrelease -s antibody_antigen_start.prepack_new.pdb

     -ensemble1 antibody_ensemble.list

    -ensemble2 antigen_ensemble.list

    -detect_disulf false

    -antibody:auto_generate_kink_constraint

    -antibody:all_atom_mode_kink_constraint

    -nstruct 20

   -multiple_processes_writing_to_one_directory > snugdock.log 2>&1 &

the process will break down after about 1 min. By using ps command to check the process, the cause of the destruction is a “segmentation fault”. 

Does anyone know how to fix this problem?

Best regards.

[Anonymous]

Segfaults tend to be hard to track down without additional information (and are absolutely an error in Rosetta – though they’re often triggered by you doing something outside of what’s expected.)

Could you re-run things but with adding `catchsegv` before the snugdock.linuxgccrelease (so you run Rosetta under the catchsegv program) and post the additional information printed by it? That should help track down what’s the issue.

[Anonymous]

Hello rmoretti, 

After adding ‘catchsegv’ before  the snugdock.linuxgccrelease, the last few lines in the snugdock.log file are: 

 

7f5bd1aa5000-7f5bd1aa7000 r-xp 00000000 fd:00 412699465 /app/rosetta_src_2017.08.59291_bundle/main/source/build/src/release/linux/3.10/64/x86/gcc/6.2/default/libdevel.so

7f5bd1aa7000-7f5bd1ca6000 —p 00002000 fd:00 412699465 /app/rosetta_src_2017.08.59291_bundle/main/source/build/src/release/linux/3.10/64/x86/gcc/6.2/default/libdevel.so

7f5bd1ca6000-7f5bd1ca7000 r–p 00001000 fd:00 412699465 /app/rosetta_src_2017.08.59291_bundle/main/source/build/src/release/linux/3.10/64/x86/gcc/6.2/default/libdevel.so

7f5bd1ca7000-7f5bd1ca8000 rw-p 00002000 fd:00 412699465 /app/rosetta_src_2017.08.59291_bundle/main/source/build/src/release/linux/3.10/64/x86/gcc/6.2/default/libdevel.so

7f5bd1ca8000-7f5bd1cac000 r-xp 00000000 fd:00 134247775 /usr/lib64/libSegFault.so

7f5bd1cac000-7f5bd1eab000 —p 00004000 fd:00 134247775 /usr/lib64/libSegFault.so

7f5bd1eab000-7f5bd1eac000 r–p 00003000 fd:00 134247775 /usr/lib64/libSegFault.so

7f5bd1eac000-7f5bd1ead000 rw-p 00004000 fd:00 134247775 /usr/lib64/libSegFault.so

7f5bd1ead000-7f5bd1ecd000 r-xp 00000000 fd:00 134247771 /usr/lib64/ld-2.17.so

7f5bd1eeb000-7f5bd1f67000 rw-p 00000000 00:00 0

7f5bd1f8c000-7f5bd20a3000 rw-p 00000000 00:00 0

7f5bd20bc000-7f5bd20ca000 rw-p 00000000 00:00 0

7f5bd20ca000-7f5bd20cc000 r-xp 00000000 00:00 0 [vdso]

7f5bd20cc000-7f5bd20cd000 r–p 0001f000 fd:00 134247771 /usr/lib64/ld-2.17.so

7f5bd20cd000-7f5bd20ce000 rw-p 00020000 fd:00 134247771 /usr/lib64/ld-2.17.so

7f5bd20ce000-7f5bd20cf000 rw-p 00000000 00:00 0

7ffdb93a5000-7ffdb93fe000 rw-p 00000000 00:00 0

ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

Could you tell the source of the segfault from them? Would it be possible to fix it?

Best regards,

 

[Anonymous]

Sorry – thanks for doing that – but looking at that I’m not any closer.

If you have a debug-mode build availible (or are willing to recompile in debug mode), redoing the ‘catchsegv’ run with the debug mode build might provide additional information.

Alternatively, I’d suggest that you double-check your input files. In particular, make sure you have the format of the ensemble lists correct, and there aren’t any issues there.

If you haven’t already, I would suggest doing a known-working example run (there should be one in the Rosetta/demos/public/antibody_docking/SnugDock/ directory, I think) to make sure you have the process down, and so that you have examples of how all the files are formatted.

[Author]

Posts