Gene-based analysis fails to match chromosomes & Window-based annotation segfaults on Linux

[silvewheat]

Hi selscan team,

Thank you for developing this great tool! I am currently using selscan v3.0.0 and attempting to perform downstream analyses using the norm subcommand with the --gene-bed option. However, I encountered some issues related to chromosome matching and platform-specific crashes.

System Environment

Platform 1: macOS (Apple Silicon M1)

Platform 2: Linux

Selscan version: v3.0.0

Issue 1: Gene-based analysis fails to match chromosomes (Both macOS and Linux)

When trying to run the gene-based analysis directly from the .ihs.out files, the program consistently throws warnings that it cannot find the corresponding chromosomes in the BED file. The run finishes, but the resulting .genetable file only contains the header row with no data.

Command used:

selscan-v3.0.0-linux norm --ihs --files out/chr*.ihs.out --gene-bed chrAll.genes.bed

Console output (Warning):

...
Annotating 29files with chrAll.genes.bed
Using 29 normalized output files for gene-based analysis.
Reading norm files for annotation...
Opening chrAll.genes.bed...
WARNING: chromosome chr1 not found in gene BED file.
WARNING: chromosome chr1 not found in gene BED file.
WARNING: chromosome chr1 not found in gene BED file.
...(same from chr1 to chr29)
WARNING: chromosome chr29 not found in gene BED file.
WARNING: chromosome chr29 not found in gene BED file.
WARNING: chromosome chr29 not found in gene BED file.
Fitted length regression: score = 0 + 0 * log(length)
Written gene table to chrAll.genes.bed.ihs.genetable

My .genes.bed file is like (tab-separated):

chr1    61442   77016   ZNF596
chr1    127739  145769  SGO1
chr1    165224  267048  KAT2B
chr1    297402  313779  PP2D1
...
chr29	46764352	46799992	VSTM5
chr29	46986113	47088628	HEPHL1
chr29	47106064	47166189	PANX1
chr29	48470624	48481156	TNFRSF10D

My .ihs.out files:

chr     id      pos     freq    ihh1    ihh0    ihs
chr1    chr1_27838      27838   0.05    0.002241        0.00313206      -0.145388
chr1    chr1_28062      28062   0.05    0.0001955       0.00185876      -0.978076
chr1    chr1_29235      29235   0.575   0.00254397      0.00384104      -0.178938
...

Troubleshooting steps I've already tried:

I ensured the chromosome names match exactly between the .ihs.out files and the .gene.bed file. I also tested both with the chr prefix (e.g., chr1) and without it (e.g., 1), but the warning persists.

I concatenated all .ihs.out files into a single merged file.

I strictly sorted the .gene.bed file to ensure the chromosome order perfectly matches the .out files.

I cleaned the BED file to ensure it's strictly tab-separated with no empty lines or weird line endings.

Despite these efforts, the "chromosome not found" issue remains.

Issue 2: Window-based annotation segfaults on Linux

I also tried the window-based annotation approach.
Interestingly, this command executes successfully on macOS (M1). However, when I run the exact same command with the exact same input files on Linux, it crashes and exits with a Segmentation fault.

Command used:

selscan-v3.0.0-linux norm --ihs --win-files out/chr*.ihs.out.100bins.norm.100kb.windows --gene-bed chrAll.genes.bed

Console output:

...
Annotating 29files with chrAll.genes.bed
You have provided 29 window files for gene annotation.
Reading gene annotations from BED file: chrAll.genes.bed
IHS_norm_window.sh: line 12: 2927816 Segmentation fault      (core dumped) selscan-v3.0.0-linux  norm --ihs  --win-files out/chr*.ihs.out.100bins.norm.100kb.windows  --gene-bed chrAll.genes.bed

Summary

1. Gene-based analysis: Fails to map chromosomes to the BED file on both Mac and Linux, resulting in an empty .genetable.

2. Window-based annotation: Works fine on Mac (M1) but throws a Segmentation fault on Linux.

Files

To help reproduce and debug these issues, I have attached my actual chr1 iHS output file and the complete gene annotation BED file to this issue. Thank you for your time and help!
chr1.iHS.ihs.out.gz
chrAll.genes.sort.bed.gz

Best,
Yudong

[silvewheat]

Hi,

I have investigated the source code and found the reason for Issue 1 (Gene-based analysis failing to match chromosomes).

In norm.cpp, line 462, the call to genex.annotateSNPs has the second parameter (useGTF) hardcoded to true:

genex.annotateSNPs(geneFile, true, normFilenames, XP, stat, minSNPs);

As defined in gene.cpp, when this parameter is true, the program invokes readGenesFromGTF. Therefore, even when a user provides a BED file via --gene-bed, the program treats it as a GTF file, fails to parse any genes, and results in the "chromosome not found" warning and an empty genetable.

I have tried changing the hardcoded true to the variable useGTF in the source code, and the program works well now.

genex.annotateSNPs(geneFile, useGTF, normFilenames, XP, stat, minSNPs);

Hope this is helpful.

Best regards,

Yudong Cai

[szpiech]

Hello, Thanks a lot for your report. This week has been quite busy, but we should be able to get to it soon.

…

-Zachary Le mer. 29 avr. 2026 à 12:13, Yudong Cai ***@***.***> a écrit :

*silvewheat* left a comment (szpiech/selscan#162) <#162 (comment)> Hi, I have investigated the source code and found the reason for Issue 1 (Gene-based analysis failing to match chromosomes). In norm.cpp, line 462, the call to genex.annotateSNPs has the second parameter (useGTF) hardcoded to true: genex.annotateSNPs(geneFile, true, normFilenames, XP, stat, minSNPs); image.png (view on web) <https://github.com/user-attachments/assets/e87fe8f2-fe13-47bb-a1fa-621456d58c8e> As defined in gene.cpp, when this parameter is true, the program invokes readGenesFromGTF. Therefore, even when a user provides a BED file via --gene-bed, the program treats it as a GTF file, fails to parse any genes, and results in the "chromosome not found" warning and an empty genetable. I have tried changing the hardcoded true to the variable useGTF in the source code, and the program works well now. genex.annotateSNPs(geneFile, useGTF, normFilenames, XP, stat, minSNPs); Hope this is helpful. Best regards, Yudong Cai — Reply to this email directly, view it on GitHub <#162 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAKRQTGQJICNRZ7JF6JP534YISZ7AVCNFSM6AAAAACYJVNQOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNBVGQ4DSOJQGU> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[silvewheat]

Hi again,

I dug a bit deeper into the source code and managed to find the cause of the Segmentation fault (Issue 2) during the window-based annotation on Linux. It turns out to be an out-of-bounds memory access in gene.cpp.

In GeneAnalyzer::annotateWindows, there is a string declaration that attempts to access chrGenes[j] right before the boundary-checking while loop:

C++

while (gene_idx < chrGenes.size() && chrGenes[gene_idx].end <= w_start) {
    gene_idx++;
}

size_t j = gene_idx;

// Out-of-bounds access if j == chrGenes.size()
std::string GENE_ID = w_chrom + "|" + chrGenes[j].name; 

while (j < chrGenes.size() && chrGenes[j].start < w_end) { ... }

When a window is located past the very last gene on a given chromosome, j equals chrGenes.size(). Accessing chrGenes[j].name at this point reads unallocated memory.

On Linux, this strictly triggers a Segmentation fault.

On macOS (Apple Silicon), the memory allocator seems to pad the vector's tail, allowing it to silently read garbage data and survive.

Since the GENE_ID variable is never actually used anywhere else in the function, I have tried deleting that line.

I tested this fix locally, and the window-based annotation now runs perfectly on Linux.

I hope these findings make it easy for you to roll out a patch!
Thanks again for the great tool!

Best regards,
Yudong Cai

[amatur]

Hi, thanks a lot for the very detailed report and for tracking down the bug. It really helped us release the patch much faster. Both issues have been fixed in v3.0.1 and are now in the main branch with updated binaries.