Re: [Discuss-gnuradio] tb lock and unlock with USRP2

[Kieran Brownlees]

There are 3 threads running, I posted thread 1 before,

Here is thread 2:

(gdb) bt
#0  0xb80ef424 in __kernel_vsyscall ()
#1  0xb80bc075 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7bcd2ab in omni_condition::wait (this=0x90059f8) at posix.cc:152
#3  0xb700ed48 in usrp2::ring::wait_for_not_empty (this=0x90059c8)
    at ring.cc:45
#4  0xb7016649 in usrp2::usrp2::impl::rx_samples (this=0x9005270, channel=0,
    handler=0x8f5e098) at usrp2_impl.cc:704
#5  0xb700fa5d in usrp2::usrp2::rx_samples (this=0x8f1af10, channel=0,
    handler=0x8f5e098) at usrp2.cc:246
#6  0xb702575f in usrp2_source_32fc::work (this=0x8fcce70, noutput_items=4081,
    address@hidden, address@hidden)
    at usrp2_source_32fc.cc:62
#7  0xb7d4d61a in gr_sync_block::general_work (this=0x8fcce70,
    noutput_items=4081, address@hidden, address@hidden,
    address@hidden) at gr_sync_block.cc:64
#8  0xb7d390f6 in gr_block_executor::run_one_iteration (this=0xb45a92d4)
    at gr_block_executor.cc:298
#9  0xb7d50502 in gr_tpb_thread_body (this=0xb45a92d4, block=
        {px = 0xb45a9324, pn = {pi_ = 0xb45a9340}}) at gr_tpb_thread_body.cc:37
#10 0xb7d4a7ba in boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>, void>::invoke (address@hidden)
    at gr_scheduler_tpb.cc:42
---Type <return> to continue, or q <return> to quit---
#11 0xb7bc4ffc in boost::function0<void, std::allocator<boost::function_base> >::operator() (this=0x8f25a6c)
    at /usr/include/boost/function/function_template.hpp:825
#12 0xb7bc5152 in boost::thread::thread_data<boost::function0<void, std::allocator<boost::function_base> > >::run (this=0x8f259b0)
    at /usr/include/boost/thread/pthread/thread.hpp:130
#13 0xb7bb7938 in thread_proxy () from /usr/lib/libboost_thread-mt.so.1.35.0
#14 0xb80b850f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#15 0xb80067ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

and Thread 3:
(gdb) bt
#0  0xb80ef424 in __kernel_vsyscall ()
#1  0xb7ffbf77 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0xb700a4a5 in usrp2::eth_buffer::rx_frames (this=0x8fcaa38, f=0x9005270,
    timeout_in_ms=100) at eth_buffer.cc:193
#3  0xb7011bb7 in usrp2::usrp2::impl::bg_loop (this=0x9005270)
    at usrp2_impl.cc:337
#4  0xb701716a in usrp2::usrp2_thread::run_undetached (this=0x8fcd058, arg=0x0)
    at usrp2_thread.cc:58
#5  0xb7bccdc1 in omni_thread_wrapper (ptr=0x8fcd058) at posix.cc:450
#6  0xb80b850f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7  0xb80067ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

On Wed, Feb 25, 2009 at 12:23 PM, Johnathan Corgan <address@hidden> wrote:

On Wed, 2009-02-25 at 12:19 +1300, Kieran Brownlees wrote:

> Here is the backtrace from the main thread:

This is showing that the main thread is stopped waiting for the
flowgraph thread to finish as a result of an internal call to stop().
Can you post the other traceback?

Johnathan