discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] usrp2 dtor can throw !


From: Josh Blum
Subject: Re: [Discuss-gnuradio] usrp2 dtor can throw !
Date: Sat, 15 Jan 2011 11:34:26 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7

I dont think that this is an issue. Are you actually seeing exceptions
thrown at deconstruction time?

There is nothing that would cause the dtor to get interrupted AFAIK. The
only way this would be an issue is when thread "A" calls interrupt() on
thread "B" when "B" is blocking in the join_all call within the
usrp2::impl::~impl(). Which could happen if you had a usrp2::impl sptr
count reset to 0 at the exit of thread "B".

On the other hand, its possible for boost::thread_interruption to be
thrown in a thread when the scheduler shuts down. This is due to the
gr-scheduler calling interrupt_all() on the thread group. If thats the
case, then the usrp2::impl thread body is probably missing a disable
interruption or a try/catch. If you are seeing an exception thrown,
maybe this is the problem?

In any case, putting a boost::this_thread::disable_interruption at the
first line of the dtor wouldnt hurt to do. :-)

-josh

On 01/14/2011 08:25 AM, Gaetano Mendola wrote:
> Hi all,
> the usrp2 destructor can throw an exeption due the fact that while
> destroying the
> implementation ( usrp2::impl::~impl() ) a stop_bg() is performed.
> 
> The stop_bg implementation is:
> 
>   void
>   usrp2::impl::stop_bg()
>   {
>     d_bg_running = false;
>     d_bg_pending_cond.notify_one(); // FIXME: check if needed
>     d_rx_tg.join_all();
>   }
> 
> indeed the boost::thread_group::join_all is an interruption point for
> boost thread.
> This can lead to a crash in case an user thread (using boost threads)
> receives an
> interruption while a stack unwinding is already occurring and an usrp2
> is destroyed.
> 
> There are two ways to correct the problem:
> 1) Instanziate a boost::this_thread::disable_interruption inside the stop_bg()
> 2) or do a try{ } catch() { } inside the impl destructor.
> 
> This is very dangerous because normaly the user code acquire a usrp instance
> with a boost::shared_ptr, I guess this was done to reliefe the user to
> perform an
> explicit delete, however due this bug the user is forced to do:
> 
> usrp2::usrp2::sptr myDevice = usrp2::usrp2::make("eth1", "", 1024*1024)
> ...
> try {
>   myDevice.reset();
> }
> catch(...) {
> }
> 
> Regards
> Gaetano Mendola
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]