Load fail of GO.db in R

Question

[T_18]

Dear all,

I am trying to run GOseq from the bioconductor package in R (via the Trinity pipeline). And get the following error:

Error: package or namespace load failed for ‘GO.db’: .onLoad failed in loadNamespace() for 'GO.db', details: call: NULL error: C stack usage 7969536 is too close to the limit

Execution halted

So there seems to be a problem with loading GO.db. Of course I googled but only found solutions in terms of using the latest R, Bioconductor and RSQLite versions. I updated all, but the error remained the same:

version.string [1] "R version 3.4.3 (2017-11-30)"

library(BiocInstaller) Bioconductor version 3.6 (BiocInstaller 1.28.0), ?biocLite for help

RSQLite version = 2.0

Is there a different approach to solve this error?

[h.mon]

Search for C stack usage is too close to the limit, you will find plenty of answers. Hint: ulimit.

[T_18]

Aha! Thanks.. So no specific R issue here.. Found the following solution: "To improve performance, we can safely set the limit of processes for the super-user root to be unlimited"

So therefor added the following line: ulimit -u unlimited using:

sudo nano /root/.bashrc

But this resulted in the same error, so seems that I made a mistake in adding the line to the file (I just pasted the line at the end of the file).

[h.mon]

You don't need to do this as root. root .bashrc settings will have no influence on this, unless you are running Trinity as root, which you shouldn't - let me repeat, you shouldn't run Trinity, nor any other analysis program, as root.

You need to do this as your user. The simplest is just to issue ulimit -u unlimited prior to running Trinity.

[T_18]

Ah, of course.. Thanks. But:

ulimit -u unlimited -bash: ulimit: max user processes: cannot modify limit: Operation not permitted

[h.mon]

And did you try:

1) to set a limit higher than your current, but not unlimited?

2) google for the new error message?

[Jean-Karim Heriche]

C stack usage 7969536 is too close to the limit

This indicates that you're running out of stack space. As the stack size is set by the system and should be sufficient for most needs (unless you changed it), this suggests a bug in the package but there could be other reasons too like libraries incompatibilities on your system. I suggest you report this to the package developers.

[T_18]

In that case would you argue against setting the stack space to unlimited (like in my reply above)?