forwarded 644962 blasts...@ncbi.nlm.nih.gov thanks Hi there!
For the BLAST folks at NCBI, please see <http://bugs.debian.org/644962>. On Tue, 11 Oct 2011 13:37:39 +0200, Olivier Sallou wrote: > I unfortunatly cannot reproduce the problem. I would need the sequence > that creates the issue, or a fake one reproducing the error. > Could be a sequence format that raise an error (bad characters?, even if > I tried to do so also). Just to repeat myself: the sequence does not seem strange at all and the fact that the BLAST website does not give any error means that it should work. FYI, BioEdit (through WINE) opens it without any problem: <http://www.mbio.ncsu.edu/BioEdit/bioedit.html> > If sending the sequence is only an issue with the fact it is logged on > public server, maybe you could send me the sequence directly. Given that the upstream BLAST authors asked to be directly contacted, do you still want to try to debug this? As I wrote, I can *privately* provide the sequence, which comes from unpublished data (and FWIW I am not working on these data). On Tue, 11 Oct 2011 17:57:54 +0200, Aaron M. Ucko wrote: > On Tue, 11 Oct 2011 16:30:01 +0200, Aaron M. Ucko wrote: >> Luca Capello <l...@pca.it> writes: >>> [3] RID 8UUGT24C013, in case someone will have access to the logs >> >> I don't have access, but will forward this report to coworkers who do. > > They report that the details already expired from their records, but > invite you to contact them directly at blasts...@ncbi.nlm.nih.gov. Done with this email, forward set as well. > FWIW, they're also preparing to issue a 2.2.26+ release that could > potentially fare better on your query. I can easily use the machine with Mac OS X 10.6.8 to test this new release if needed: all the necessary software to build BLAST+ is already installed there. Should any pre-release be tested, feel free to provide a link to the tarball or a VCS repository. >>> Warning: (802.8) NULL pointer found in container: skipping >> >> It looks like you're somehow getting NULL results mixed in; raw ASN.1 >> output elides them, but other formats entail further processing that >> doesn't allow for that possibility (which shouldn't happen, to be fair). >> It's hard to tell exactly why, particularly without access to your query >> data (whose confidentiality I understand); however, repeating the failing >> commands with the environment setting EXCEPTION_STACK_TRACE_LEVEL=Debug >> may shed some light on the matter. Could you please do so? Even worse ;-) ===== (sid)root@gismo:/srv# export | grep EXCEPTION_STACK_TRACE_LEVEL (sid)root@gismo:/srv# export EXCEPTION_STACK_TRACE_LEVEL=Debug (sid)root@gismo:/srv# time blastp -query [SEQUENCE-8].fasta \ -db /srv/blastDB/swissprot -out [SEQUENCE-8].asn1.num-threads-1.debug \ -evalue 0.001 -num_threads 1 -outfmt 11 Segmentation fault real 0m1.796s user 0m0.168s sys 0m0.240s (sid)root@gismo:/srv# dmesg | tail -n 1 [17411.690415] blastp[31722]: segfault at 7fff9f272ff8 ip 00007fd1e8839378 \ sp 00007fff9f273000 error 6 in libstdc++.so.6.0.16[7fd1e8780000+e5000] (sid)root@gismo:/srv# time blastp -query [SEQUENCE-8].fasta \ -db /srv/blastDB/swissprot -out [SEQUENCE-8].xml.num-threads-1.debug \ -evalue 0.001 -num_threads 1 -outfmt 5 Segmentation fault real 0m0.479s user 0m0.172s sys 0m0.200s (sid)root@gismo:/srv# dmesg | tail -n 1 [17448.907143] blastp[31852]: segfault at 7fff8b36dff8 ip 00007f34bd5d34b0 \ sp 00007fff8b36e028 error 6 in libstdc++.so.6.0.16[7f34bd531000+e5000] (sid)root@gismo:/srv# time blastp -query [SEQUENCE-8].fasta \ -db /srv/blastDB/swissprot -out [SEQUENCE-8].no-outfmt.num-threads-1.debug \ -evalue 0.001 -num_threads 1 Segmentation fault real 0m0.501s user 0m0.160s sys 0m0.220s (sid)root@gismo:/srv# dmesg | tail -n 1 [17471.719104] blastp[31924]: segfault at 7fff6f04fff8 ip 00007f914aa7abd6 \ sp 00007fff6f050000 error 6 in libc-2.13.so[7f914aa06000+17a000] (sid)root@gismo:/srv# ===== Thx, bye, Gismo / Luca
pgpPnPKxVQb7q.pgp
Description: PGP signature
