🚀 go-pugleaf

Hi.

WU BLAST 2.0 has just started misbehaving on my Origin 200 machine; it
crashes with even quite simple queries.  It didn't do this until a few
days ago, but I simply do not understand what could have caused the
behaviour I am seeing.  Perhaps you could shed some light.

First of all, the machine is a four CPU Origin 200 with 1 GB RAM.  Blast
format databases created with GCG Wisconsin Package are in /data/gcgblast.

I create a tiny example query sequence:
           
>
PSTAIRE

which might (if I'm lucky) pick up some cyclin dependent kinases, although
it's probably to short to be successful.  I then run the following
commands (the shell is bash):

export BLASTDB=/data/gcgblast
export BLASTFILTER=/biosoft/bin/blast2/filter
/biosoft/bin/blast2/blastp owl sqfile E=10 V=100 H=1 -matrix \
/biosoft/bin/blast2/matrix/aa/BLOSUM62 -filter XNU+SEG

which produces the following:

BLASTP 2.0a8MP-WashU [25-Feb-1997] [Build 20:41:24 Feb 25 1997]

Reference:  Gish, Warren (1994-1997).  unpublished.
Altschul, Stephen F., Warren Gish, Webb Miller, Eugene W. Myers, and David J.
Lipman (1990).  Basic local alignment search tool.  J. Mol. Biol. 215:403-10.

Query=          (7 letters)
 
Database:  owl
           191,509 sequences; 60,552,547 total letters.
Searching
m_fork: Not enough space
Segmentation fault (core dumped)

On double checking what the program was doing using 'par', I see this:  

 4071mS sigprocmask(SIG_SETMASK, <NO_SIGNALS>, 0) OK
 6304mS sproc(0xfa54a94, PR_SPROC|PR_SFDS|PR_SDIR|PR_SUMASK|PR_SULIMIT|PR_SID|PR_SADDR, 0x1) = 13747
 6306mS sproc(0xfa54a94, PR_SPROC|PR_SFDS|PR_SDIR|PR_SUMASK|PR_SULIMIT|PR_SID|PR_SADDR, 0x2) = 13500
 6317mS sproc(0xfa54a94, PR_SPROC|PR_SFDS|PR_SDIR|PR_SUMASK|PR_SULIMIT|PR_SID|PR_SADDR, 0x3) errno = 12 (Not enough space)
 6318mS kill(13747, SIGKILL) OK
 6318mS kill(13500, SIGKILL) OK
 6318mS stat(/usr/lib/locale/C/LC_MESSAGES/uxsyserr, 0x7fff27e8) errno = 2 (No such file or directory)
 6318mS stat(/usr/lib/locale/C/Xopen/LC_MESSAGES/uxsyserr, 0x7fff27e8) errno = 2 (No such file or directory)
 6318mS write(2, "\nm_fork", 7) = 7
 6318mS write(2, ": ", 2) = 2
 6318mS write(2, "Not enough space", 16) = 16
 6318mS write(2, "\n", 1) = 1

Now according to sproc(2) this error is returned if the machine runs out
of virtual memory when allocating the stack.  But this is clearly
ridiculous;  the machine has 1 GB RAM, of which nearly 800 MB was free at
the time of the test.  The resource limits as set in the IRIX kernel are
also very high:

        rlimit_vmem_max = 9223372036854775807 (0x7fffffffffffffff) ll 
        rlimit_vmem_cur = 9223372036854775807 (0x7fffffffffffffff) ll 
        rlimit_core_max = 9223372036854775807 (0x7fffffffffffffff) ll
        rlimit_core_cur = 9223372036854775807 (0x7fffffffffffffff) ll
        rlimit_stack_max = 536870912 (0x20000000) ll
        rlimit_stack_cur = 67108864 (0x4000000) ll
        rlimit_data_max = 9223372036854775807 (0x7fffffffffffffff) ll
        rlimit_data_cur = 9223372036854775807 (0x7fffffffffffffff) ll
        rlimit_fsize_max = 9223372036854775807 (0x7fffffffffffffff) ll
        rlimit_fsize_cur = 9223372036854775807 (0x7fffffffffffffff) ll
        rlimit_cpu_max = 9223372036854775807 (0x7fffffffffffffff) ll
        rlimit_cpu_cur = 9223372036854775807 (0x7fffffffffffffff) ll

Or is that rlimit_stack_cur possibly too small for BLAST 2.0?  I haven't  
updated the database since this was last working though, so I can't see
why this would suddenly have changed.

So, do you have any idea what might have gone wrong to cause this error,
and what I might try to do to correct it?  Many thanks in advance for your
help.

Tim.

--
--------------------------------------------------------------------------
T J R Cutts                                           Tel: +44 1223 333596
Dept. of Biochemistry, Tennis Court Rd.,              Fax: +44 1223 766002
Cambridge, CB2 1QW, UK