Thure wrote:
>
> I found the bug, in fact there were two:
>> 1) edit file src/icarus.c
>> after line 670 you find
>> if (!IcaCursorIsInput (job->inCursor, job->cursor)) {
> /* CursorDelete (&job->cursor); */
> job->cursor = NULL;
>> }
>> remove the comments and rebuild srsbuild:
>> srsmake srsbuild
>> 2) edit icarus/db/embl.is
>> around line 55 you find
>> seq: ~ (/.*2BIT *Len:/ /[0-9]+/ {$len=$Ct} ln ln
> {$s=$SeqGet2Bit:[$s file:$File len:$len]} ('>>>>'{$Not} ln)*|
> /.*ASCII/ ln ln ('>>>>' {$Not} /.*/ {$SeqApp:[$s
> s:$Ct]})+) ~
>> change '$s=$SeqGet2Bit' to '$SeqGet2Bit'
>> regards
> thure
Despite the changes, I seem to have a memory problem. I tried to
index the new EMBL release this weekend, and it crashed with this
message:
...no. 720600, MJU67483
SRSDB:embl.is:72: error: insufficient memory - error during malloc,
could not allocate "sequence"
I retried, but now tracked memory usage during srsbuild, and it
appears that after writing a subindex (*_1.inx etc), memory usage
hardly decreases, and continues to increase when srsbuild works
further through the database. I would expect that a significant
amount of memory would be freed after writing an index file, or
that memory usage almost stops growing after writing the first one.
Is it possible there is a problem with freeing/reallocating memory
after a subindexfile has been written ?
This was with gcg formatted embl. I also made changes to the
embl.i and embl.is files, but I don't really think that causes the
problem (Ofcourse I might be completely wrong with that :-))
Cheers,
Martin
--
-----------------------------------------------------------------
| Martin Hilbers | E-mail: m.p.hilbers at dl.ac.uk |
| SEQNET | Tel: +44-1925-603492 |
| Daresbury Laboratory | Fax: +44-1925-603100 |
| Daresbury, Warrington |---------------------------------------|
| Cheshire WA4 4AD | SEQNET is the UK national EMBNet node |
| United Kingdom | http://www.dl.ac.uk/SEQNET/home.html |
-----------------------------------------------------------------
