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.
Category:
Post Situation:
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.
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,
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.