Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
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_ite...@0xb59e12f8, output_ite...@0xb59e1318)
at gr_message_source.cc:96
#5 0xb7d0437a in gr_sync_block::general_work (this=0x912ad80,
noutput_items=32768, ninput_ite...@0xb59e12ec, input_ite...@0xb59e12f8,
output_ite...@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_invoker0gruel::thread_body_wrappertpb_container,
void::invoke (function_obj_p...@0x912d558)
at gr_scheduler_tpb.cc:42
#9 0xb7b7bffc in boost::function0void,
std::allocatorboost::function_base ::operator() (this=0x912d554)
at /usr/include/boost/function/function_template.hpp:825
#10 0xb7b7c152 in boost::thread::thread_databoost::function0void,
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%27t-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.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
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%27t-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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
On Sun, May 17, 2009 at 07:34:16PM -0700, Ling Huang wrote: 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? No. You can find out where it's hung by running gdb. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
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_pgr_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 Blossom wrote: No. You can find out where it's hung by running gdb. Eric -- View this message in context: http://www.nabble.com/Can%27t-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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
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%27t-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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
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%27t-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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
On Fri, May 15, 2009 at 05:51:30PM -0700, Ling Huang wrote: 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Can't stop the top_block which contain transmit_path
Hi, all
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.
---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%27t-stop-the-top_block-which-contain-transmit_path-tp23555109p23555109.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path
On Fri, May 15, 2009 at 12:55:20AM -0700, Ling Huang wrote: Hi, all 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. What version of GNU Radio are you using? We fixed a problem in the trunk about a month ago that could be related to this. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path
What version of GNU Radio are you using? my GNU Radio version is 10853 -- View this message in context: http://www.nabble.com/Can%27t-stop-the-top_block-which-contain-transmit_path-tp23555109p23557528.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path
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. Eric Blossom wrote: On Fri, May 15, 2009 at 12:55:20AM -0700, Ling Huang wrote: Hi, all 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. What version of GNU Radio are you using? We fixed a problem in the trunk about a month ago that could be related to this. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/Can%27t-stop-the-top_block-which-contain-transmit_path-tp23555109p23562707.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
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%27t-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.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
