Dear list,

occasionally (possibly a race condition) our application 
crashes with a stack trace like this:

{what}: suspending thread while at least one lock is being 
held, stack backtrace: 27 frames:
0x7fddfe5ba98f  : ??? + 0x7fddfe5ba98f in 
0x7fddfe5baace  : ??? + 0x7fddfe5baace in 
0x7fddfe5b4471  : 
hpx::detail::backtrace_direct[abi:cxx11](unsigned long) + 
0x23 in /usr/local/lib/
0x7fddff17f875  : hpx::util::verify_no_locks() + 0xb3 in 
0x7fddfef4881f  : 
boost::intrusive_ptr<hpx::threads::thread_data> const&, 
hpx::util::thread_description const&, hpx::error_code&) + 
0x87 in /usr/local/lib/
0x91a1b3        : 
hpx::util::thread_description const&, hpx::error_code&) + 
0x40 in [...]
0x91a301        : 
hpx::lcos::local::spinlock::yield(unsigned long) + 0x6e in 
0x91a409        : hpx::lcos::local::spinlock::lock() + 
0x3f in [...]
0x9251f6        : 
+ 0x2a in [...]
0x7fde0024f01f  : 
CommunicationHandler::expectImage(hpx::naming::id_type) + 
0x91 in [...]/build/

What I make out of this, is this:
One of our threads holds a lock, then requests another but 
this second one is already locked, so it tries to suspend, 
which is not allowed while holding a lock?

However the task CommunicationHandler::expectImage that 
yields this error should hold no locks prior to requesting 
the spinlock that causes the suspend.

Here are my questions:
Is my interpretation of the occurring events that lead to 
this error correct?
For what purpose is it illegal to suspend while holding a 
Is there a way to query the number and or nature of locks 
currently held by the executing thread?
Different tasks spawned by (possibly remote) asynchronous 
calls may be run in the same hpx worker thread... is it 
possible for a threads different tasks to influence each 
other regarding something like held locks?

Best regards,

Kilian Werner
hpx-users mailing list

Reply via email to