# Why is my STAR reference genome indexing aborting on my GNU/Linux server but not on my Mac OS X laptop?

I am running the following command to index my genome:

STAR --runThreadN 8 --runMode genomeGenerate --genomeDir output/index/star --genomeFastaFiles ref.fa --sjdbGTFfile ref.gff3 --sjdbGTFtagExonParentTranscript Parent --sjdbOverhang 100

and I get the following output:

Feb 27 10:27:37 ..... started STAR run
Feb 27 10:27:37 ... starting to generate Genome files
Feb 27 10:27:40 ... starting to sort Suffix Array. This may take a long time...
Feb 27 10:27:42 ... sorting Suffix Array chunks and saving them to disk...
Feb 27 10:28:30 ... finished generating suffix array
Feb 27 10:28:30 ... generating Suffix Array index
terminate called after throwing an instance of 'std::bad_alloc'


Searches for the GNU/Linux error lead to some pages about C++ that I don't understand.

Submitting it as a batch job works fine but I would like to know why it does not work on a node. It is quite practical for me to test small code like this without submitting a batch job.

The command above works fine on my laptop running Mac OSX.

The STAR version is STAR_2.5.3a on both computers: STAR_2.5.3a

The memory usage of the node is the following:

total            used       free     shared    buffers       cached

251              251         0         0       0             232


so, is there 0 memory for me to use on this node?

Why is my indexing aborting?

• Are they the same version of STAR? Compiled with the same flags? Do you have enough RAM on the node you are using? Feb 27 '18 at 12:28
• What do you mean by 'compiled with the same flags'? I have installed STAR using conda from the bioconda channel. Do you know how I can check the available RAM on my node? Feb 27 '18 at 12:58
• That will depend on how your system is set up, but if you have ssh access to your node, you can just run free -h (or just free) to see available memory. That said, you usually don't want to be running things directly from the nodes. Most such systems will have a queuing tool that will distribute jobs across nodes and that will help you avoid this type of problem, and ignoring the queue means i) you may well have the kind of problem you are encountering and ii) you are being rude to the other users of the system; you are effectively cutting the queue. Feb 27 '18 at 13:05

A std::bad_alloc error tends to mean that you've run out of memory. It's not unusual for head nodes to be fairly limited in capacity, so presumably that's the issue.