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
