Can't stop the top_block which contain transmit_path with GNU Radio version 11001


#1

sorry for attaching this again.
I use UBUNTU 9.04 + gnuradio 11001 and UBUNTU 8.10 +gnuradio 10853 got
the
same problem.

I modify the gnuradio-examples/python/digital codes for some
experiences. In
one case I want to stop the running flow graph(top block), and then to
start
a new connect. I do it well in stop the receive_path connect. But I just
can’t stop the top block contain a transmit_path. If I stop the top
block,
and wait, it hang in the tb.wait.
I seem not express well. To make it simple let’s see:
class my_topblock(gr.top_block)
def init(self):
self.trans=transmit_path(…)
self.connect(self.trans)

tb.start()
tb.stop()
tb.wait() # IT HANG IN HERE

tb.start()

I made a simple test code to test stopping the top block , please test
it to
see what’s the problem.

ps.Eric,
would you please tell me what cause tb.wait() hanging, where is this bug
from?
I have install the newest version of GNU Radio, but the problem is still
the
same.

-------------------------------code--------------------------------------------------------
#!/usr/bin/env python

from gnuradio import gr, gru, modulation_utils
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import random, time, struct, sys

from current dir

from transmit_path import transmit_path
import fusb_options

class my_top_block(gr.top_block):

def __init__(self,mod_class,options):
    gr.top_block.__init__(self)
    self.txpath = transmit_path(mod_class, options)
    self.connect(self.txpath);

def main():
mods = modulation_utils.type_1_mods()
parser = OptionParser(option_class=eng_option,
conflict_handler=“resolve”)
expert_grp = parser.add_option_group(“Expert”)
parser.add_option("-m", “–modulation”, type=“choice”,
choices=mods.keys(),
default=‘gmsk’,
help=“Select modulation from: %s
[default=%%default]”%
(’, '.join(mods.keys()),))
transmit_path.add_options(parser, expert_grp)
for mod in mods.values():
mod.add_options(expert_grp)
r = gr.enable_realtime_scheduling()
fusb_options.add_options(expert_grp)
(options, args) = parser.parse_args ()

tb=my_top_block(mods[options.modulation], options)

tb.start()
tb.stop()
print "afater stop"
tb.wait()
print "wait done"
tb.start()
print "start again"

if name == ‘main’:
try:
main()
except KeyboardInterrupt:
pass


View this message in context:
http://www.nabble.com/Can't-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23569318.html
Sent from the GnuRadio mailing list archive at Nabble.com.


#2

On Fri, May 15, 2009 at 05:51:30PM -0700, Ling H. wrote:

I seem not express well. To make it simple let’s see:
tb.start()

I made a simple test code to test stopping the top block , please test it to
see what’s the problem.

Some block is most likely blocked in a system call. I’m guessing that
the transmit path is hung in gr.message_source waiting for a message
that’s never coming. To get it to stop, send it a message with
type=1. The message source will indicate that it is done and the flow
graph will terminate.

Eric


#3

< To get it to stop, send it a message with
<type=1. The message source will indicate that it is done and the flow
<graph will terminate.

I set transmit path message with type = 1, but it still not work, it
hang in
wait() either.

Will the USRP block the system?

View this message in context:
http://www.nabble.com/Can't-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23590147.html
Sent from the GnuRadio mailing list archive at Nabble.com.


#4

On Sun, May 17, 2009 at 07:34:16PM -0700, Ling H. wrote:

Will the USRP block the system?
No.

You can find out where it’s hung by running gdb.

Eric


#5

sorry, I’m not familiar with gdb, I can’t get many useful infomation
from
that.
The topblock start 6 threads (exept the mainloop) . After tb.stop(),
five
threads has exited, but leaving one.
Here is the gdb infomation after tb.stop()
------------------------------------gdb-------------------------------------------------------------
(gdb) bt
#0 0xb7f87430 in __kernel_vsyscall ()
#1 0xb7f41075 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7bd7e17 in boost::condition_variable::wait (this=0x97285f0,
m=@0xbff885b0)
at /usr/include/boost/thread/pthread/condition_variable.hpp:35
#3 0xb7a3a1f2 in boost::thread::join ()
from /usr/lib/libboost_thread-mt-d.so.1.35.0
#4 0xb7a4b223 in gruel::thread_group::join_all (this=0x9728224)
at thread_group.cc:78
#5 0xb7bcf4a0 in gr_scheduler_tpb::wait (this=0x9728220)
at gr_scheduler_tpb.cc:94
#6 0xb7bd57c9 in gr_top_block_impl::wait (this=0x9684a18)
at gr_top_block_impl.cc:124
#7 0xb7bd5080 in gr_top_block::wait (this=0x96aab50) at
gr_top_block.cc:71
#8 0xb7bd5168 in ~gr_top_block (this=0x96aab50) at gr_top_block.cc:51
#9 0xb7c6fc58 in
boost::detail::sp_counted_impl_p<gr_hier_block2>::dispose
(
this=0x97095c0) at /usr/include/boost/checked_delete.hpp:34
#10 0xb7c5bd30 in _wrap_delete_gr_top_block_sptr (args=0xb595ea6c)
at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145
#11 0x08062646 in PyObject_CallFunctionObjArgs ()
#12 0xb7c471b9 in PySwigObject_dealloc (v=0xb5b9de60)
at gnuradio_swig_py_runtime.cc:1452
#13 0x08088e54 in ?? ()
#14 0x0809ff8b in ?? ()
#15 0x08088e54 in ?? ()
#16 0x0809ff8b in ?? ()
#17 0x081161cf in ?? ()
#18 0x080cfc13 in PyEval_EvalFrameEx ()
#19 0x080d0345 in PyEval_EvalCodeEx ()
#20 0x080d0557 in PyEval_EvalCode ()
#21 0x080edf8f in PyRun_FileExFlags ()
#22 0x080ee25a in PyRun_SimpleFileExFlags ()
#23 0x080595e7 in Py_Main ()
#24 0x08058962 in main ()

Eric B. wrote:


View this message in context:
http://www.nabble.com/Can't-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23608703.html
Sent from the GnuRadio mailing list archive at Nabble.com.


#6

And here is the gdb after tb.wait()
-----------------------------------------------gdb
wait-------------------------------------------
#0 0xb7f1f430 in __kernel_vsyscall ()
#1 0xb7e1bdf1 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7efbbc9 in ?? () from /usr/lib/python2.5/lib-dynload/time.so
#3 0x080cea39 in PyEval_EvalFrameEx ()
#4 0x080d0345 in PyEval_EvalCodeEx ()
#5 0x080ce728 in PyEval_EvalFrameEx ()
#6 0x080d0345 in PyEval_EvalCodeEx ()
#7 0x080ce728 in PyEval_EvalFrameEx ()
#8 0x080cfbf5 in PyEval_EvalFrameEx ()
#9 0x080cfbf5 in PyEval_EvalFrameEx ()
#10 0x080cfbf5 in PyEval_EvalFrameEx ()
#11 0x080d0345 in PyEval_EvalCodeEx ()
#12 0x080d0557 in PyEval_EvalCode ()
#13 0x080edf8f in PyRun_FileExFlags ()
#14 0x080ee25a in PyRun_SimpleFileExFlags ()
#15 0x080595e7 in Py_Main ()
#16 0x08058962 in main ()


View this message in context:
http://www.nabble.com/Can't-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23608871.html
Sent from the GnuRadio mailing list archive at Nabble.com.


#7

actually, the code is hanging in the gr_message. To stop the message,
not to
set in the pkt.py, but to set send_pkt(eof=True) to stop the message
thread.
It now work good.
Thank Eric!

View this message in context:
http://www.nabble.com/Can't-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23628077.html
Sent from the GnuRadio mailing list archive at Nabble.com.


#8

sorry for before attachments. maybe those infomations are nonsensed. I
dig
gdb and do some homework, find out that the backtrace should be these:
I did set message type=1 but there is still a thread in message. How can
I
get rid of these threads that can’t quit?
-----------------------------------------gdb thread apply all backtrace
after tb.wait()-------------------------------------------------------
Thread 3 (Thread 0xb59e1b90 (LWP 11153)):
#0 0xb80b7430 in _kernel_vsyscall ()
#1 0xb8071075 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7b842ab in omni_condition::wait (this=0x912ae74) at posix.cc:152
#3 0xb7cfc0b3 in gr_msg_queue::delete_head (this=0x912ae58)
at gr_msg_queue.cc:81
#4 0xb7cce6bc in gr_message_source::work (this=0x912ad80,
noutput_items=32768, input_items=@0xb59e12f8,
output_items=@0xb59e1318)
at gr_message_source.cc:96
#5 0xb7d0437a in gr_sync_block::general_work (this=0x912ad80,
noutput_items=32768, ninput_items=@0xb59e12ec,
input_items=@0xb59e12f8,
output_items=@0xb59e1318) at gr_sync_block.cc:64
#6 0xb7ceef76 in gr_block_executor::run_one_iteration (this=0xb59e12d4)
at gr_block_executor.cc:298
#7 0xb7d07267 in gr_tpb_thread_body (this=0xb59e12d4, block=
{px = 0xb59e1324, pn = {pi
= 0x0}}) at gr_tpb_thread_body.cc:40
#8 0xb7d0151a in
boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>,
void>::invoke (function_obj_ptr=@0x912d558)
at gr_scheduler_tpb.cc:42
#9 0xb7b7bffc in boost::function0<void,
std::allocatorboost::function_base >::operator() (this=0x912d554)
at /usr/include/boost/function/function_template.hpp:825
#10 0xb7b7c152 in boost::thread::thread_data<boost::function0<void,
std::allocatorboost::function_base > >::run (this=0x912d498)
at /usr/include/boost/thread/pthread/thread.hpp:130
#11 0xb7b699c2 in thread_proxy () from
/usr/lib/libboost_thread-mt-d.so.1.35.0
#12 0xb806d50f in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
#13 0xb7fbba0e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb27fbb90 (LWP 11159)):
#0 0xb80b7430 in _kernel_vsyscall ()
#1 0xb8071075 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7d07e17 in boost::condition_variable::wait (this=0x912d4c8,
m=@0xb27fa730)
at /usr/include/boost/thread/pthread/condition_variable.hpp:35
#3 0xb7b6a1f2 in boost::thread::join ()
from /usr/lib/libboost_thread-mt-d.so.1.35.0
#4 0xb7b7b223 in gruel::thread_group::join_all (this=0x912d0fc)
at thread_group.cc:78
#5 0xb7cff4a0 in gr_scheduler_tpb::wait (this=0x912d0f8)
at gr_scheduler_tpb.cc:94
#6 0xb7d057c9 in gr_top_block_impl::wait (this=0x910de48)
at gr_top_block_impl.cc:124
#7 0xb7d05080 in gr_top_block::wait (this=0x90e9268) at
gr_top_block.cc:71
#8 0xb7d833af in top_block_wait_unlocked (r=
{px = 0xb27fa80c, pn = {pi
= 0xb27fa828}})
at gnuradio_swig_py_runtime.cc:4865
#9 0xb7d8d4d6 in _wrap_top_block_wait_unlocked (args=0xb5a9118c,
kwargs=0xb5a9b68c) at gnuradio_swig_py_runtime.cc:15264
#10 0x0805d867 in PyObject_Call ()
#11 0x080cd502 in PyEval_EvalFrameEx ()
#12 0x080d0345 in PyEval_EvalCodeEx ()
#13 0x080ce728 in PyEval_EvalFrameEx ()
#14 0x080cfbf5 in PyEval_EvalFrameEx ()
#15 0x080cfbf5 in PyEval_EvalFrameEx ()
#16 0x080d0345 in PyEval_EvalCodeEx ()
#17 0x08117891 in ?? ()
#18 0x0805d867 in PyObject_Call ()
#19 0x08063a7a in ?? ()
#20 0x0805d867 in PyObject_Call ()
#21 0x080c850c in PyEval_CallObjectWithKeywords ()
#22 0x080f9e68 in ?? ()
#23 0xb806d50f in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
#24 0xb7fbba0e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb7ed98c0 (LWP 11152)):
#0 0xb80b7430 in __kernel_vsyscall ()
#1 0xb7fb3df1 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb8093bc9 in ?? () from /usr/lib/python2.5/lib-dynload/time.so
#3 0x080cea39 in PyEval_EvalFrameEx ()
#4 0x080d0345 in PyEval_EvalCodeEx ()
#5 0x080ce728 in PyEval_EvalFrameEx ()
#6 0x080d0345 in PyEval_EvalCodeEx ()
#7 0x080ce728 in PyEval_EvalFrameEx ()
#8 0x080cfbf5 in PyEval_EvalFrameEx ()
#9 0x080cfbf5 in PyEval_EvalFrameEx ()
#10 0x080cfbf5 in PyEval_EvalFrameEx ()
#11 0x080d0345 in PyEval_EvalCodeEx ()
#12 0x080d0557 in PyEval_EvalCode ()
#13 0x080edf8f in PyRun_FileExFlags ()
#14 0x080ee25a in PyRun_SimpleFileExFlags ()
#15 0x080595e7 in Py_Main ()
#16 0x08058962 in main ()


View this message in context:
http://www.nabble.com/Can't-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23611034.html
Sent from the GnuRadio mailing list archive at Nabble.com.