Tweet
ok thanks again.
I will let you know any news and I will upgrade to the 0.6.4b.
All the best
I will let you know any news and I will upgrade to the 0.6.4b.
All the best
-
Last edited by blu78; 04-11-2010, 12:01 PM. -
It seems I am having the same problem...
I am using bfast-0.6.4 and I set the number of threads to 8 I got the "Segmentation fault" error. However when I set it to 4, BFAST works just fine. Was this problem solved?
Thanks!Comment
-
Could you post the results of the "configure" command (during install)?Originally posted by fennan View PostComment
-
Hi,
We have the same problem with debian Lenny 64bits: bfast (0.6.4d but also 0.6.2a and 0.6.3c) crashes when running with 8 CPU but not with 4 (our server has 32 cores so we would really want to use as many resources as possible.
- The configuration phase is the same as blue78 : http://pastebin.com/vW9kXwX9
- It generates the following config.h : http://pastebin.com/gk57XfP9
- and for the compilation: http://pastebin.com/jBLjyL2s (it complains a bit about gzread64 not being declared but nothing wrong during the linking)
We are running the folowwing commands:
The result isCode:WORK_DIR=/data/ngs/solid/PROJETS/Comp_bowtie_bfast/BFAST REF_GENOME=/data/ngs/annotations/bfast_indexes/hg19.fa BFAST_BIN_DIR=/bioinfo/local/build/bfast_0.6.4d/bin NB_THREADS=8 nohup $BFAST_BIN_DIR/bfast match -f $REF_GENOME -n $NB_THREADS -A 1 -r $WORK_DIR/FastQ/reads100000.200.fastq > $WORK_DIR/Bmf/bmfbfast.matches.file.hg19.200.bmf
and the it crashes with a segfault.Code:************************************************************ Checking input parameters supplied by the user ... Validating fastaFileName /data/ngs/annotations/bfast_indexes/hg19.fa. Validating readsFileName /data/ngs/solid/PROJETS/Comp_bowtie_bfast/BFAST/FastQ/reads100000.200.fastq. Validating tmpDir path ./. **** Input arguments look good! ************************************************************ ************************************************************ Printing Program Parameters: programMode: [ExecuteProgram] fastaFileName: /data/ngs/annotations/bfast_indexes/hg19.fa mainIndexes [Auto-recognizing] secondaryIndexes [Not Using] readsFileName: /data/ngs/solid/PROJETS/Comp_bowtie_bfast/BFAST/FastQ/reads100000.200.fastq offsets: [Using All] loadAllIndexes: [Not Using] compression: [Not Using] space: [Color Space] startReadNum: 1 endReadNum: 2147483647 keySize: [Not Using] maxKeyMatches: 8 maxNumMatches: 384 whichStrand: [Both Strands] numThreads: 8 queueLength: 250000 tmpDir: ./ timing: [Not Using] ************************************************************ Searching for main indexes... Found 10 index (10 total files). Not using secondary indexes. ************************************************************ Reading in reference genome from /data/ngs/annotations/bfast_indexes/hg19.fa.cs.brg. In total read 25 contigs for a total of 3095693983 bases ************************************************************ Reading /data/ngs/solid/PROJETS/Comp_bowtie_bfast/BFAST/FastQ/reads100000.200.fastq into a temp file. Will process 100000 reads. ************************************************************ Searching index file 1/10 (index #1, bin #1)... Reading index from /data/ngs/annotations/bfast_indexes/hg19.fa.cs.1.1.bif. Read index from /data/ngs/annotations/bfast_indexes/hg19.fa.cs.1.1.bif. Reads processed: 100000 Cleaning up index. Searching index file 1/10 (index #1, bin #1) complete... Found 60065 matches. ************************************************************ Searching index file 2/10 (index #2, bin #1)... Reading index from /data/ngs/annotations/bfast_indexes/hg19.fa.cs.2.1.bif.
We generated a core dump but the crash is in a function of libz so we installed the debug version of libz and here is the result: http://pastebin.com/Ae0re589
So if you have any leads, I would be happy to help and test.
Best regardsLast edited by cbarette; 08-02-2010, 07:31 AM.Comment
-
Thank-you for providing a good amount of info to help my debug. Googling the compiler warning, it may be the case that your zlib is buggy in Ubuntu (see my links hinting at that). The function "gzopen64" is declared in zlib to provide 64-bit support, but is not being declared correctly. I am guessing it crashes when trying to read in a compressed index (as shown by the last BFAST status message). In "configure.ac", could you change the "extended_CFLAGS" line to the below and see what happens?extended_CFLAGS="-m64 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE";The run "sh autogen.sh && ./configure && make".
Links:
Comment
-
Hi,
Thanks a lot for your feedback ! With this modification bfast runs perfectly with 8 threads.
CheersComment
-
I’m not a sequencing expert. I’m a purification scientist who uses NGS to evaluate workflows my group develops. With this perspective, we think about the sample first and the NGS workflow second. The sequencer is an exceptionally honest reporter, but it can only report on what you give it, so whether you get clean, interpretable data from an NGS workflow is largely determined before you begin.
Here are nine questions we think about, in roughly the order they matter, before...06-18-2026, 07:11 AM -
Data variability is still an issue in sequencing technologies despite the advances in reproducibility and accuracy of these platforms. But the problem does not originate in the sequencing itself, but in the previous steps, before the sample reaches the sequencer.
The first step is collection, followed by preservation and sample preparation for analysis. Most scientists overlook those steps, but not being careful might just be skewing the experiment’s results.
...06-02-2026, 10:05 AM
Comment