VAMOS Segmentation Fault During Chromosomal Processing

[alyazeeditalal]

Issue Description

VAMOS consistently crashes with segmentation fault during read phasing, particularly when processing chromosomes 5, 9, and Y.

Environment

• System: SLURM cluster node with 64 CPUs, 1TB RAM
• VAMOS version: 2.1.7
• Input: Sorted, aligned BAM files with read groups
• Reference: GRCh38

Command Used

vamos -t 12 --read -b "samples_fastq/${sample}/aligned/${sample}.sorted.aligned.RG.bam" -r "references/vamos.effMotifs-0.3.GRCh38.tsv" -s "${sample}" -o "${output_dir}/${sample}.vamos.reads.vcf"

Error Output

Phasing reads in chr9:35513232-65963886
Storing TR sequences on chrY:26496657-57215892
Phasing reads in chrY:26496657-57215892
Clearing IO
/var/spool/slurmd/job192532/slurm_script: line 65: 4166957 Segmentation fault (core dumped)

Troubleshooting Attempted

• Reduced threads from 32 → 12 (segfault persists)
• Verified BAM file integrity with samtools quickcheck
• confirmed sufficient memory (>350GB available)
• Tested with multiple samples (all fail at similar chromosomal regions)

Pattern Observed

• Consistently fails during chromosome Y processing
• Also observed failures on chr5 and chr9
• Crashes occur during "Phasing reads" or "Storing TR sequences" steps

[mchaisso]

Thanks for the detailed report. I'll see if I can replicate locally. Is this by any chance on a public dataset?

[alyazeeditalal]

These data not available online, these are my own data actually. I run out of memory even when using a node with a large memory 1TB and reduced threads 8-12. I suspect the tool buffer large amounts of genomic data in memory. It will possibly potentially to resolve this it temp files were directed else where. I have yet to try this work around.

[mchaisso]

Phasing is done in small batches, so it shouldn't use too much memory. I just ran phasing on HG002 ONT data with this version and it did not have problems. Since it reaches the end of phasing before crashing, it means there was some memory overwriting issue.

[mchaisso]

Alternatively, is this pacbio or ONT data? Also, is this a male or female sample? If you are able to perform a clean build: make clean Edit the makefile for the line: CFLAGS = -g -std=c++14 #-fsanitize=address -static-libasan -gdwarf-4 #-Wall -Wextra to be: CFLAGS = -g -std=c++14 -fsanitize=address #-static-libasan -gdwarf-4 #-Wall -Wextra Then: make DEBUG=TRUE Finally, run vamos in gdb, and show where it is crashing, I can pinpoint the error.

…

On Wed, Aug 6, 2025 at 11:16 PM alyazeeditalal ***@***.***> wrote: *alyazeeditalal* created an issue (ChaissonLab/vamos#22) <#22> Issue Description VAMOS consistently crashes with segmentation fault during read phasing, particularly when processing chromosomes 5, 9, and Y. Environment - *System*: SLURM cluster node with 64 CPUs, 1TB RAM - *VAMOS version*: 2.1.7 - *Input*: Sorted, aligned BAM files with read groups - *Reference*: GRCh38 Command Used vamos -t 12 --read -b "samples_fastq/${sample}/aligned/${sample}.sorted.aligned.RG.bam" -r "references/vamos.effMotifs-0.3.GRCh38.tsv" -s "${sample}" -o "${output_dir}/${sample}.vamos.reads.vcf" Error Output Phasing reads in chr9:35513232-65963886 Storing TR sequences on chrY:26496657-57215892 Phasing reads in chrY:26496657-57215892 Clearing IO /var/spool/slurmd/job192532/slurm_script: line 65: 4166957 Segmentation fault (core dumped) Troubleshooting Attempted - Reduced threads from 32 → 12 (segfault persists) - Verified BAM file integrity with samtools quickcheck - confirmed sufficient memory (>350GB available) - Tested with multiple samples (all fail at similar chromosomal regions) Pattern Observed - Consistently fails during chromosome Y processing - Also observed failures on chr5 and chr9 - Crashes occur during "Phasing reads" or "Storing TR sequences" steps — Reply to this email directly, view it on GitHub <#22>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKPGPXDHGIRUNVOEXH22TL3MLVKJAVCNFSM6AAAAACDJ6ZBSWVHI2DSMVQWIX3LMV43ASLTON2WKOZTGI4TSMJUG4YDINY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bw2]

I've found that one reason vamos can segfault is if I run it on a .bam file with a missing index (.bai) file.

[alyazeeditalal]

@mchaisso Thank you for the quick response here is the error after using the -dbug flag. I have installed vamos through conda since I don't have the privileges in the cluster for the suggested work around.

(base) [alyazeedit@mbru-tgen-head01 cluster_logs]$ tail -n 50 vamos_193066.err
h2
TATATATATATATATATATATATATATATATATT
34  1
0,0,0,0,0,0
h1
GAAAAAAAAAAAAAAAAAAAAA
22  0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

h2
GAAAAAAAAAAAAAAA
16  1
0,0,0,0,0,
,0,0,0,0,0,0start to do the annotation: 361178
,0,0,0,0,0,0,0,
start to do the annotation: 361042

h1
AAAAAAAAAGATGACACTAATAATAAAAATAAATAATAATTGTACTTGTAATATA
55  0
1,1,1,0,3,4,0,0,0,1,0,0,0,2,0,2,0,0,

h2
AAAAAAAAGATGACACTAATAATAAAAATAAATAATAATTGTACTTGTAATATA
54  1
1,1,1,3,4,0,0,0,1,0,0,0,2,0,2,0,0,
start to do the annotation: 361043

h1
GTGCAGGGGGGCTGCCGGCCTCCTGGGTGCAGGGGGGCTGCCGGCCTCCTGGGGTGCAGGG
61  0
2,1,

h2
GTGCAGGGGGGCTGCCGGCCTCCTGGGTGCAGGGGGGCTGCCGGCCTCCTGGGGTGCAGGG
61  1
2,1,
start to do the annotation: 361044

h1
CCTCCTCCTCCTCCCTCTCCCCCTC
25  0
0,0,0,0,0,0,0,0,

h2
CATCCTCCTCCTCCTCTTCCCTC
23  1
0,0,0,0,0,0,0,
start to do the annotation: 361045
/var/spool/slurmd/job193066/slurm_script: line 64: 582447 Segmentation fault      (core dumped) vamos -t 4 --read -b "${input_bam}" -r "${motif_file}" -s "${sample}" -o "${output_vcf}" --debug
(base) [alyazeedit@mbru-tgen-head01 cluster_logs]$ tail -n 50 vamos_193066.out
Done processing chr4:75663367-78265692
Done processing chr4:78265692-80752472
Done processing chr4:83097269-85436088
Done processing chr4:80752472-83097269
Done processing chr4:85436088-87559953
Done processing chr4:87559953-90055357
Done processing chr4:90055357-92471951
Done processing chr4:92471951-94644044
Done processing chr4:96934589-99513701
Done processing chr4:94644044-96934589
Done processing chr4:99513701-101952099
Done processing chr4:101952099-104490950
Done processing chr4:104490950-107036318
Done processing chr4:107036318-109480482
Done processing chr4:109480482-111864441
Done processing chr4:111864441-114205106
Done processing chr4:114205106-116379310
Done processing chr4:118621602-121117563
Done processing chr4:116379310-118621602
Done processing chr4:123560905-125833147
Done processing chr4:121117563-123560905
Done processing chr4:125833147-128129364
Done processing chr4:128129364-130484913
Done processing chr4:130484913-132547591
Done processing chr4:132547591-134821050
Done processing chr4:134821050-136907849
Done processing chr4:139264843-141663869
Done processing chr4:136907849-139264843
Done processing chr4:141663869-144254125
Done processing chr4:144254125-146880976
Done processing chr4:146880976-149474205
Done processing chr4:151864604-154219991
Done processing chr4:154219991-156586099
Done processing chr4:149474205-151864604
Done processing chr4:156586099-159050223
Done processing chr4:159050223-161205355
Done processing chr4:161205355-163164367
Done processing chr4:163164367-165288846
Done processing chr4:165288846-167491176
Done processing chr4:169859719-172150277
Done processing chr4:167491176-169859719
Done processing chr4:172150277-174484624
Done processing chr4:174484624-176785038
Done processing chr4:176785038-179003468
Done processing chr4:179003468-181019764
Done processing chr4:183173061-185398814
Done processing chr4:181019764-183173061
Done processing chr4:185398814-187608959
VAMOS analysis failed for sample: APR001
Check error logs and core dump files

[alyazeeditalal]

@bw2 Thanks for the suggestion I'll check the index

[mchaisso]

@bw2 Good catch, I'll add a check in the code to report problems opening the index.

[mchaisso]

I've posted a new version that avoids crashing on read input in the master branch.