Bug #477

gnuradio locks in thread interrupt call

Added by Josh Blum over 1 year ago. Updated 3 months ago.

Status:Closed Start date:12/27/2011
Priority:High Due date:
Assignee:- % Done:

0%
Category:gnuradio-core
Target version:-
Resolution:wontfix

Description

tested on ubuntu 11.10 x64, the python app test2-gr-lockup.py consistently locks up when run

one of the calls to thread.interrupt() does not return. This should be a non-blocking call.

test2-gr-lockup.py (1.1 kB) Josh Blum, 12/27/2011 08:23 am

History

#1
Updated by Josh Blum over 1 year ago

It looks like the problem here lies within boost itself.

Until boost 1.47 a deadlock condition existed durring concurrent
condition_wait() and interrupt() calls, which is what we are running into.
this seems to happen most commonly as a TPB thread body is blocking on
an input condition variable while the python/top-level thread is calling
unlock() --> interrupt() which blocks on a thread_info mutex.

see https://svn.boost.org/trac/boost/ticket/4978

The boost minimum requirement in GNU Radio should probable be raised to
1.47 (or at least some kind of warning added) in order to avoid this
behavior in the future.

test2.py seems to run without any issues or deadlock using boost 1.48
from source.

-Tim

#2
Updated by Tom Rondeau 5 months ago

  • Status changed from New to Feedback
  • Resolution set to wontfix

I think we have to leave this issue alone since it's a bug with Boost and not us. They have fixed this in later versions, though.

The build guide on the website makes a note of the issue and recommends not using 1.47. Also, we'll probably make a change in version 3.7 that either makes the minimum requirement 1.48 or maybe just specifically rejects 1.47 (by editing GrBoost.cmake).

#3
Updated by Johnathan Corgan 3 months ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF