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

BUG: Signal4.1 segfaults using docker #92

Open
krostifangers opened this issue Mar 8, 2023 · 7 comments
Open

BUG: Signal4.1 segfaults using docker #92

krostifangers opened this issue Mar 8, 2023 · 7 comments
Labels
bug Something isn't working

Comments

@krostifangers
Copy link

Hello
I tried to use Predector with the test dataset, in order to check for the good installation of the different programs.
I ran the nextflow run -profile test,docker -resume -r 1.2.7 ccdmb/predector command -line and after several seconds I get the following :

Execution cancelled -- Finishing pending tasks before exit
Error executing process > 'signalp_v4 (2)'

Caused by:
Process signalp_v4 (2) terminated with an error exit status (65)

Command executed:

CHUNKSIZE="$(decide_task_chunksize.sh in.fasta "4" 100)"

parallel --halt now,fail=1 --joblog log.txt -j "4" -N "${CHUNKSIZE}" --line-buffer --recstart '>' --cat 'signalp4 -t "euk" -f short "{}"' < in.fasta | cat > out.txt

predutils r2js --pipeline-version "1.2.7" --software-version "4.1g" -o out.ldjson signalp4 out.txt in.fasta

Command exit status:
65

Command output:
(empty)

Command error:
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Failed to parse file <out.txt> at line 8.

The line had the wrong number of columns. Expected 12 but got 11

Work dir:
/home/krostif/prog_secretome/work/95/040e4802a86a04f622386b0edec96f

Tip: you can try to figure out what's wrong by changing to the process work dir and showing the script file named .command.sh

Here is the out.txt file

SignalP-4.1g euk predictions

name Cmax pos Ymax pos Smax pos Smean D ? Dmaxcut Networks-used

SignalP-4.1g euk predictions

name Cmax pos Ymax pos Smax pos Smean D ? Dmaxcut Networks-used

SignalP-4.1g euk predictions

name Cmax pos Ymax pos Smax pos Smean D ? Dmaxcut Networks-used

SignalP-4.1g euk predictions

name Cmax pos Ymax pos Smax pos Smean D ? Dmaxcut Networks-used

                       0.000   1  0.000   1  0.000   1  0.000   0.000 N  0.450      SignalP-noTM
                       0.000   1  0.000   1  0.000   1  0.000   0.000 N  0.450      SignalP-noTM
                       0.000   1  0.000   1  0.000   1  0.000   0.000 N  0.450      SignalP-noTM
                       0.000   1  0.000   1  0.000   1  0.000   0.000 N  0.450      SignalP-noTM

I am running the predector pipeline on Debian 11 with a docker installation.
I cannot figure out where the problem is.
If you can help me.
Thank you in advance
All the best
Christophe

@krostifangers krostifangers added the bug Something isn't working label Mar 8, 2023
@darcyabjones
Copy link
Member

Hi Christophe,

Thanks for reporting the problem.
I'll have to look into it tonight and see if i can reproduce it.

Can I please check whether the debian installation is running on WSL, or is it a pure debian virtual machine etc?
Also, what CPU architecture is it? I.e. Intel/AMD (x86) or ARM?

I know that both of these can cause issues, though I thought with docker it should be ok.

If you're interested, below is what I think is happening.
It's similar to some problems i've encountered before.

Cheers,
Darcy

From the error report, the issue seems to be that something in SignalP4 is not compatible with something about your environment. Segfaults indicate that the program has tried to access invalid memory, in the case of these older programs its usually trying to execute code from the C-libraries that doesn't exist anymore.
Then later (Because SignalP4 doesn't return proper exit codes to say there was an error) we try to parse the output which is missing some columns that would normally be created by the segfaulting code. That causes the "Expected 12 but got 11" error.

I'll have to look at library compatibility and see.

Feel free to send and more details or ask questions :)

@krostifangers
Copy link
Author

I am running on a pure debian 11, not WSL, on a Intel/AMD(x86) processor 64bits.

@krostifangers
Copy link
Author

Hi
Did you find something concerning SignalP4.1?
Thank you in advance

@stuart897
Copy link

stuart897 commented May 12, 2023

We have experienced the same issue, running via Singularity on Debian 11 x86_64 (physical server), please see attached logfile predector_errors.txt , thanks

./nextflow run -with-singularity "predector.sif" -resume -r 1.2.7 ccdmb/predector --proteome ptr_effectors_all.fa

@darcyabjones
Copy link
Member

Hi both of you.

I'm so sorry for the long delay.
I've finally had some time to look at this again.

I haven't been able to reproduce the specific errors that you've described, but i've been encountering several other issues with getting older compiled software to work.
Oddly, this seems to mainly be a problem with the containers.
Conda still works for me.

I think it might be time to retire signalp 3 and 4.
I don't have a good idea yet of how to deal with this.

Will keep in touch,

Darcy

@ibebio
Copy link

ibebio commented Apr 3, 2024

We had a segfault in the signalp_v3_nn process, when using singularity containers, resulting in the error message

open: can't stat file
apparent state: unit 3 named input.how
lately reading sequential formatted external IO

and a subsequent segfault.
The solution was to let SignalP run on a local filesystem, instead of a networked one, by setting the working directory to /tmp.
This can be done by adding the following to the nextflow.config in the directory where the pipeline is run:

process {
   withName: /^signalp_v3_.*/ {
        scratch = '/tmp'
   }
}

Perhaps this might help with the other SignalP related problems.

@darcyabjones
Copy link
Member

Thanks @ibebio

I'll add it to the FAQ/troubleshooting sections as a possible solution.
This strikes me as something that would be specific to a person's compute environment, so probably providing it as an additional config option via e.g. -c https://www.nextflow.io/docs/latest/config.html

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

4 participants