Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Control: reassign -1 kaptive 0.7.3-1 Andreas Tille writes: > Thanks a lot. Its very relieving to know a competent person behind > this I appreciate the kind words, but am alas unclear on where precisely BLAST+ is going wrong here. That said, I do see that future releases will incorporate an overhaul of some of the relevant portions of libseqdb, which with any luck will help in the long term, but which I'd rather not try to backport at this stage of the release cycle. The good news is that in response to previous issues along these lines (e.g., https://bugs.debian.org/970344), kleborate already supports retrying in single-threaded mode under some circumstances; kaptive just needs to indicate that it should do so, which it currently does only for much older versions. I'll extend the relevant version range shortly, and am reassigning this bug accordingly. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
On Fri, Apr 09, 2021 at 08:13:52AM -0400, Aaron M. Ucko wrote: > Don't worry, I am still looking into this crash, and had primarily > intended that comment as a public note to myself -- the crash occured > within a (presumably valid) call to ncbi-blast+, and wound up taking > quite a few tries to reproduce on the porterbox I was using (amdahl), so > once I finally obtained more details, I wanted to make very sure I > wouldn't be able to lose them. Sorry for any resulting confusion. Thanks a lot. Its very relieving to know a competent person behind this Andreas. -- http://fam-tille.de
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Andreas Tille writes: > Thanks a lot for your investigation. Unfortunately I have no idea how > to proceed from here. Does anybody have an idea? I mean a better idea > than just stating this package does not work on arm64 which would > probably some last resort. Don't worry, I am still looking into this crash, and had primarily intended that comment as a public note to myself -- the crash occured within a (presumably valid) call to ncbi-blast+, and wound up taking quite a few tries to reproduce on the porterbox I was using (amdahl), so once I finally obtained more details, I wanted to make very sure I wouldn't be able to lose them. Sorry for any resulting confusion. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Hi Aaron, On Fri, Apr 09, 2021 at 12:01:21AM -0400, Aaron M. Ucko wrote: > Never mind, this appears to be a different issue, per a backtrace > obtained with EXCEPTION_STACK_TRACE_LEVEL=Error and a great deal of > patience: > > Error: tblastn encountered an error: > terminate called after throwing an instance of 'ncbi::CMutexException' > what(): NCBI C++ Exception: > T29 "c++/include/corelib/ncbidiag.hpp", line 417: Error: > (CMutexException::eOwner) > ncbi::ncbi_namespace_mutex_mt::SSystemMutex::ThrowNotOwned() - Mutex is not > owned by current thread > Stack trace: > /usr/lib/ncbi-blast+/libxncbi.so ???:0 > ncbi::CMutexException::CMutexException(ncbi::CDiagCompileInfo const&, > ncbi::CException const*, ncbi::CMutexException::EErrCode, > std::__cxx11::basic_string, std::allocator > > const&, ncbi::EDiagSev) offset=0x3C addr=0x83061d9c > /usr/lib/ncbi-blast+/libxncbi.so ???:0 > ncbi::ncbi_namespace_mutex_mt::SSystemMutex::ThrowNotOwned() offset=0x88 > addr=0x82f76534 > /usr/lib/ncbi-blast+/libxncbi.so ???:0 > ncbi::ncbi_namespace_mutex_mt::SSystemMutex::Unlock(ncbi::ncbi_namespace_mutex_mt::SSystemFastMutex::ELockSemantics) > offset=0x78 addr=0x83057938 > /usr/lib/ncbi-blast+/libseqdb.so ???:0 > ncbi::CSeqDBLockHold::~CSeqDBLockHold() offset=0x30 addr=0x84305fa0 > /usr/lib/ncbi-blast+/libseqdb.so ???:0 > ncbi::CSeqDBImpl::GetSeqLength(int) const offset=0x48 addr=0x8432ca1c > /usr/lib/ncbi-blast+/libblast.so ???:0 BLAST_SetupPartialFetching > offset=0x134 addr=0x84442904 > /usr/lib/ncbi-blast+/libblast.so ???:0 offset=0x27938 > addr=0x8441f938 > /usr/lib/aarch64-linux-gnu/libgomp.so.1 ???:0 offset=0x18CB0 > addr=0x81f19cb0 > /lib/aarch64-linux-gnu/libpthread.so.0 ???:0 offset=0x8628 > addr=0x82027628 > /lib/aarch64-linux-gnu/libc.so.6 ???:0 offset=0xD601C > addr=0x82c2001c Thanks a lot for your investigation. Unfortunately I have no idea how to proceed from here. Does anybody have an idea? I mean a better idea than just stating this package does not work on arm64 which would probably some last resort. Kind regards Andreas. -- http://fam-tille.de
