DeltaGroupNJUPT/Vina-GPU

Segmentation fault issue

Glinttsd opened this issue · 10 comments

Glinttsd commented

Segmentation fault issues like:

./Vina-GPU --config 2bm2_config.txt

Reading input ... done.
Setting up the scoring function ... done.
Analyzing the binding site ... done.
Using random seed: -1098921832
Segmentation fault (core dumped)

are probably cause by stack overflow,

try ulimit -s to check the stack size and set the stack size to 8MB (or larger) by ulimit -s 8192

kyowilson commented

Hi! I'd try the ulimit -s 8192, even more, but I'm still having this error (segmentation fault... Core dumped). Could I do another thing that solve this problem?

  • 👀1
BJWiley233 commented

Me as well.

igor611 commented

Hi! I have got the same problem then trying to start Vina-GPU from python by subprocess.Popen() or subprocess.call(). Problem was solved then I use cwd param
subprocess.call(dock_cmd, shell=True, cwd=vina_GPU_working_dir)
there vina_GPU_working_dir is a path to Vina-GPU
I think Vina-GPU needs to start in she's worcking directory

jjlex commented

I have the same segmentation fault problem. The ulimit -s 8192 doesn't work for me. I even tried ulimit -s unlimited.

Looks like it reports this error when running the code:
parallel_iter_instance.run(task_container); // line 76 of parallel_mc.cpp

Any idea to resolve this problem?

jjlex commented

I tried to run gdb to get more information on the segmentation fault problem. The output of running Vina-GPU is as the following:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
#################################################################
If you used Vina-GPU in your work, please cite: #
#
Shidi, Tang, Chen Ruiqi, Lin Mengru, Lin Qingde, #
Zhu Yanxiang, Wu Jiansheng, Hu Haifeng, and Ling Ming. #
Accelerating AutoDock VINA with GPUs. ChemRxiv (2021).Print. #
#
And also the origin AutoDock Vina paper: #
O. Trott, A. J. Olson, #
AutoDock Vina: improving the speed and accuracy of docking #
with a new scoring function, efficient optimization and #
multithreading, Journal of Computational Chemistry 31 (2010) #
455-461 #
#
DOI 10.1002/jcc.21334 #
#
#################################################################

Reading input ... done.
Setting up the scoring function ... done.
Analyzing the binding site ... done.
Using random seed: -1792850808
[New Thread 0x7ffff6852700 (LWP 1574194)]

Platform: NVIDIA CUDA[New Thread 0x7ffff4b9e700 (LWP 1574218)]
[New Thread 0x7fffedc80700 (LWP 1574219)]
[New Thread 0x7fffed47f700 (LWP 1574220)]
[New Thread 0x7fffecc7e700 (LWP 1574221)]
[New Thread 0x7fffe7fff700 (LWP 1574222)]
[New Thread 0x7fffe77fe700 (LWP 1574223)]

Device: Tesla K80
[New Thread 0x7fffe6ffd700 (LWP 1574225)]

Thread 2 "Vina-GPU" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6852700 (LWP 1574194)]
0x00007ffff784f4a7 in __GI_fseek (fp=0x0, offset=0, whence=2) at fseek.c:35
35 fseek.c: No such file or directory.

the 'bt' command of gbd gives:

#0 0x00007ffff784f4a7 in __GI_fseek (fp=0x0, offset=0, whence=2) at fseek.c:35
#1 0x00005555555f7166 in SetupBuildProgramWithBinary(_cl_context*, _cl_device_id**, char const*) ()
#2 0x00005555555b70f6 in monte_carlo::operator()(model&, boost::ptr_vector<output_type, boost::heap_clone_allocator, void>&, precalculate const&, igrid const&, precalculate const&, igrid const&, vec const&, vec const&, incrementable*, boost::random::mersenne_twister_engine<unsigned int, 32ul, 624ul, 397ul, 31ul, 2567483615u, 11ul, 4294967295u, 7ul, 2636928640u, 15ul, 4022730752u, 18ul, 1812433253u>&) const ()
#3 0x00005555555c72c8 in boost::detail::thread_data<boost::reference_wrapper<parallel_for<parallel_iter<parallel_mc_aux, boost::ptr_vector<parallel_mc_task, boost::heap_clone_allocator, void>, parallel_mc_task, true>::aux, true>::aux> >::run() ()
#4 0x00005555555f8ae2 in thread_proxy ()
#5 0x00007ffff79d9609 in start_thread (arg=)
at pthread_create.c:477
#6 0x00007ffff78e3293 in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

by the way, the 'ulimit -s' command returns 8192.

Can anyone help diagnose this problem?

Glinttsd commented

Hi, I think you have to 1. make sure you have Kernel2_Opt.bin (if not, pls check out README) and 2. put Kernel2_Opt.bin and Vina-GPU binary in the same directory (because Vina-GPU needs to read Kernel2_Opt.bin).

The segmentation fault issue is highly caused by not finding Kernel2_Opt.bin

  • 👍4
igor611 commented
  • 👍1
BJWiley233 commented

@Glinttsd the documentation is not so clear on HOW to create Kernel2_Opt.bin. When I run make source, where should this file/binary exist? If I have to actually run the program to make it exist, then this will not fly for those who are making Dockerfiles with Vina-GPU to run on GPU on say a cluster. If so could you please compile a docker image and add to the releases?

I tried running on my cluster and I was able to create the Kernel2_Opt.bin on my cluster, copy it back to my Dockerfile, recompile with make and still even with this Kernel file in the same directory as Vina-GPU and still get a Seg fault.

Update:
Ok so doing all the above + running ulimit -s 8192 no longer Seg faults but instead no I get this

Search depth is set to 10
Vina-GPU: ./lib/monte_carlo.cpp:309: void monte_carlo::operator()(model&, output_container&, const precalculate&, const igrid&, const precalculate&, const igrid&, const vec&, const vec&, incrementable*, rng&) const: Assertion `m.num_other_pairs() == 0' failed.
Aborted (core dumped)
  • 😕1
cewinharhar commented

Same error as @BJWiley233

But it only occurs when using the flexibel docking with --flex

shogo-d-nakamura commented

In my case, I was able to verify the operation by copying Kernel1_Opt.bin and Kernel2_Opt.bin from the Vina-GPU+ directory to the working directory.