Core dumped segmentation fault (with 2.3.1 and 2.3.4)

[sbridel]

Hello, I know there are some thread about apparent memory issues. So far, I run gubbins on 50 genomes + a ref on Intel Xeon (32 apparent cores) and 62GB RAM. I wonder how a program can run out of memory on such a config. I have never issued memory crashes using this computer...

I try gubbins with 2.3.1 or manually installed from git (2.3.4) but the segmentation fault is still there. 2.3.1 was installed with conda. $run_gubbins.py --v 2.3.1

AND from manually installed PATH/TO/GIT/REPO/python/scripts/run_gubbins.py -v 2.3.4

Fun fact: I ran Gubbin on the same species but with another ref (which is included in the above-mentionned 50 genomes) and everything worked well and the stats are quiet similar to what I was exepecting (because several papers have made comparative genomics on the species).

The average SNPs against my ref is around 10000 (snippy stats)

What is different between my refs? The first I used was one of the most divergent. The second I used (which lead to systematic segmentation fault), is include in the biggest clonal complex I have (around 50% of my genomes).

Why I use another ref since the first was ok for me? My PhD Supervisor wonder how the ref could change the stats computed by Gubbins...

So, do you have any idea? What tricks can I test to highlight what is going on.

Thanks

[puethe]

Hi, can you please be more specific: With which version did you get the segfault - 2.3.1 or 2.3.4? This is a known problem in 2.3.1 that was fixed in 2.3.4, but I don't want to exclude the possibility that something else can cause a segfault in 2.3.4. The segfault has nothing to do with memory, this is just the default error message issued by the software. In case you get the segfault with 2.3.4, could you please make your data available in some way, and provide us with the precise command you used to call Gubbins. We can then check.