Hi all - in case anyone else runs across this problem with ControlFreeC, I'm posting this here. ControlFreeC (in tumor-only mode, on WES) was repeatedly seg faulting on two of my samples. The .nextflow.log would always show a crash in "freec -conf config.txt" with exitcode 139.

..calculating medians for 21
  ..calculating medians for 22
  ..calculating medians for X
  ..annotate copy numbers
  .command.sh: line 60:    65 Segmentation fault      (core dumped) freec -conf config.txt

Work dir:
  /home/ec2-user/wes/work/7f/7934db123d056275a5cf21741b2b69

Container:
  quay.io/biocontainers/control-freec:11.6b--hdbdd923_0

I had plenty of memory allocated so it didn't look like an OOM issue. Running freec standalone (outside of the pipeline) also replicated the crash, confirming it was a problem with freec itself. GDB identified the problem - a vector called breakpoints was occasionally empty, and the code would call breakpoints.back() without checking, leading to the segfault. Adding a line to handle this edge case fixed the issue -- I posted it to the github with hopes that it'll get patched in the next release (https://github.com/BoevaLab/FREEC/issues/164). I couldn't find this problem reported anywhere else so it must not be triggered commonly - out of >100 samples, this only happened in two samples. Not sure if it has to do with the breakPointThreshold of 1.2 in config.txt (too high?). It's patched now on my local machine and manually running the patched freec binary works, but I'd rather keep the workflow as simple/reproducible with as little manual work as possible. The github repo isn't particularly active so I'm wondering if the best solution for now is to feed sarek a config file that looks for the ControlFreeC process and points to a custom docker container with the patched binary

Congratulations on identifying the root cause of the bug and finding a solution. The ideal solution would be for this to be fixed upstream and then incorporated into the next module update and sarek version. In reality, this may take a while, if it ever happens. Since you have a well-defined patch, nf-core might incorporate that into the hosted containers (and thus sarek) -- is that a "thing", @Maxime Garcia, @Rike Hanssen? Or could the fix be incorporated e.g. at the level of BioContainers (if they would do that)? Maintaining patches for mutiple tools can quickly become unmanageable, but if the tool is important and doesn't change often, it could be worthwhile ... For your own purposes, since you have the container, it's easy enough to have a config file:

process {
    withName: 'FREEC_.*' { // I hope that catches all the relevant processes
        container = '/path/to/custom_freec.img'
    }
}

The compilation of all software versions used by sarek happens by running the respective tool with something like

-v

and capturing the output. If you wanted that to distinguish between the patched and unpatched Control-FREEC versions, you would have to patch the code printing the version as well.

amaze ghe easiest way for us would be if you'd update the bioconda recipe (also most benefit to everyone). Do you htink that would be possible?

Amazing catch

Thanks all - I submitted a pull request to the controlfree-c recipe in bioconda: https://github.com/bioconda/bioconda-recipes/pull/63245