[mira_talk] Re: Crash: "Would extend memory of AS_skim_edges? Shouldn't be. "
- From: John Nash <john.he.nash@xxxxxxxxx>
- To: mira_talk@xxxxxxxxxxxxx
- Date: Fri, 19 Oct 2012 10:51:36 -0400
On 2012-10-15, at 5:56 PM, Bastien Chevreux wrote:
> On Oct 15, 2012, at 23:45 , John Nash wrote:
>> One of my students reported a crash while assembling a 5 mb prokaryote
>> genome. I got him to repeat it and the same thing happened. I have snipped
>> some of the 'head' and 'tail' of the assembly log, and can make the log
>> available to email back-channel (It's only 27 K). I have also attached the
>> manifest file. The log and checkpoint directories are intact - I can zip
>> them up and put them on a shared dropbox folder if needed.
>
> Stop the press! I.e., please keep the whole directory as it is, make a copy
> of it to run further tests if you want, but keep a complete copy archived
> somehow :-)
>
>>
>> The student has successfully assembled about 25 other bacterial genomes with
>> mira, so he pretty much knows his way around the process, therefore I would
>> discount user error. At the time, we had plenty of RAM and processors free
>> as we limit our jobs to avoid clogging the beast. We run a bit of a mira
>> factory so we are aware of clogging up our computer with mira jobs. Usually
>> we only run 2-3 mira jobs at a time on that server. So hopefully running
>> too many mira jobs is not the cause of the crash.
>>
>> I'll also get him to repeat the assembly with one processor, as I recall
>> something like this from the recent past - is this your elusive randomly
>> occuring SKIM bug?
>
> It's one of the two Heisenbugs which make me sweat (the other one being that
> something's completely broken on Mac for bigger projects).
>
> Let's see ... can you please test the following (after having made a complete
> copy):
> - in the run which failed, can you please run with the "-r" (resume) option.
> If it crashes, things are looking good. If not, I'd need the complete log of
> the run that crashed and would then send you a specially crafted version.
> - in parallel or if the above fails, re-running with one processor to see
> whether it crashes there would be nice.
>
> Short explanation of the above: I have the slight feeling that a part of the
> non-reproducability of the problem lies in memory allocation, so having a
> reproducible case would be really smashing.
>
> Best,
> Bastien
Hi Bastien,
Bad news... it's not mira.
I went to the lab out in the boonies yesterday and looked at the student's
assembly after running mira -r, and the results did not make sense, i.e. mira
completed the job in a normal manner and ditched out no contigs. So I decided
to repeat the job myself. Four of the five SFF files which came from the
sequence provide were corrupt, sff_extract complained, and the student either
did not notice or did not understand (my fault for not teaching him properly).
I could still let you have the data but it's probably useless.
My apologies for exciting you prematurely.
John
--
You have received this mail because you are subscribed to the mira_talk mailing
list. For information on how to subscribe or unsubscribe, please visit
http://www.chevreux.org/mira_mailinglists.html
Other related posts:
