Option 1: Technical & Direct (Recommended for lab notes/GitHub issues)

• English: Troubleshooting Modkit Repair Exit Status 134 in nf-core/methylong: Fixing Unsorted BAM Files
• Chinese: 解决 nf-core/methylong 流程中 Modkit Repair 退出码 134 错误：修复未排序的 BAM 文件

Option 2: Action-Oriented (Focuses on the solution)

• English: Resolving Modkit Memory Corruption Errors in Nextflow by Enforcing Queryname BAM Sorting
• Chinese: 通过强制 BAM 文件按读段名称 (queryname) 排序来解决 Nextflow 中 Modkit 的内存损坏错误

Option 3: Short & Concise (Best for a quick file name or subject line)

• English: Fixing Modkit Repair (Exit 134) Errors in methylong Pipeline
• Chinese: 修复 methylong 流程中 Modkit Repair (退出码 134) 错误指南

It is completely understandable why this is confusing! If the pipeline step is the same, why would it fail on 4 samples but succeed on 10?

Here is the exact reason why this happens, followed by a “magic” command to fix all the failing samples at once so you don’t have to do it manually.

Why did 10 samples succeed while 4 failed?

As we saw in the header, the failing files have SO:unsorted but GO:query. This means the reads are grouped by name, but not strictly sorted alphabetically.

modkit is written in C++ and uses a streaming algorithm that strictly expects alphabetical order (SO:queryname). When it encounters reads that are out of order, it holds them in a temporary memory buffer until it finds their match.

• For the 10 successful samples, the reads just happened to be mostly in order by chance, or the files were small enough that the memory buffer never overflowed.
• For O_rep2 and WT_Trans_rep2 (and likely 2 others), the specific distribution of reads, read lengths, or adapter trimming artifacts caused the out-of-order buffer to overflow, resulting in the catastrophic memory corruption (malloc_consolidate error).

The “Magic” Fix (Fix all samples at once)

Instead of hunting down the work directory for every single failing sample, you can run a single bash command that will search your entire work directory, find every unsorted *_after_trim.bam file, and fix them all in place.

Run this exact block of code in your terminal:

# Find all acceptor BAMs in the work directory and fix them if they are unsorted
find /mnt/md1/DATA/Data_Tam_Methylation_2026_WT_T_O_T_Trans_O_Trans/methylome_out_4mC_5mC_rep/work -name "*_after_trim.bam" | while read f; do
  if samtools view -H "$f" | grep -q "SO:unsorted"; then
    echo "🔧 Fixing: $f"
    samtools sort -n -o "${f%.bam}_fixed.bam" "$f"
    mv "${f%.bam}_fixed.bam" "$f"
  else
    echo "✅ Already sorted: $f"
  fi
done

or fixing specific BAM-file

WORK_DIR="/mnt/md1/DATA/Data_Tam_Methylation_2026_WT_T_O_T_Trans_O_Trans/methylome_out_4mC_5mC_rep/work/26/2af6e00c550b522637c4a5b4a62d17"

cd "$WORK_DIR"
# Force sort by queryname, overwriting the existing file
samtools sort -n -o O_rep2_after_trim_fixed.bam O_rep2_after_trim.bam
mv O_rep2_after_trim_fixed.bam O_rep2_after_trim.bam

# Verify it worked
samtools view -H O_rep2_after_trim.bam | grep "^@HD"
# MUST output: @HD VN:1.6 SO:queryname

Next Steps

Once that script finishes running (it will print out which files it fixed), all your input files for modkit repair will now have the correct SO:queryname header.

Now, simply go back to your main project directory and resume the pipeline. Nextflow will see that the files have been modified, invalidate the cache for the 4 failing samples, and re-run them successfully:

cd ~/DATA/Data_Tam_Methylation_2026_WT_T_O_T_Trans_O_Trans

nextflow run nf-core/methylong -r 2.0.0 -profile docker \
        --input samplesheet_4mC_5mC_rep.csv \
        --outdir methylome_out_4mC_5mC_rep \
        --ont_aligner minimap2 \
        --all_contexts \
        --skip_snvs \
        -resume \
        -work-dir methylome_out_4mC_5mC_rep/work

(Note: If you ever run into this again in future runs, this is technically a bug in the nf-core/methylong pipeline. The upstream trimming step should be enforcing samtools sort -n before passing the BAM to modkit. You might want to consider opening a quick issue on their GitHub repository!)