Can you suggest what can be the problem and what can I do to solve it.
Thanks
Kaleem Ahmad
Not sure where it’s actually blowing up (definitely a bug somewhere).
A stack trace from gdb would provide clues.
However, the flow graph you give above is doomed to fail. It will
sooner or later exhaust all memory on your system. When this happens
is should fail gracefully, but it may not.
Can you give me a bit more explanation about why it is ‘doomed to fail
and
will sooner or later exhaust all memory’. Actually my plan is to run
this
graph for ever and I dont have any idea why a graph(especially this one)
will exhibit such behavior and what measure can be taken to avoid
this…?
Addition to my above question I also want to know how can I connect two
different flowgraphs with ‘usrp.source_c’,
I was trying following
src = usrp.source_c(…)
fg.connect((src, 0),…blocks of fg1)
fg.connect((src, 1),…blocks of fg2)
But it is not working I got following error
"Traceback (most recent call last):
File “./usrp_Master.py”, line 309, in
fg = my_graph()
File “./usrp_Master.py”, line 87, in init
self.rxpath = receive_path(options, times)
File “/usrp/cognitive/gr-comac1.0/src/python/receive_path.py”, line
227,
in init
self.connect((self.u,1), self.s2v)
File
“/usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py”,
line 50, in connect
self._connect(points[i-1], points[i])
File
“/usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py”,
line 56, in _connect
dst_block.basic_block(), dst_port)
File
“/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py”,
line 946, in connect
return _gnuradio_swig_py_runtime.gr_hier_block2_sptr_connect(*args)
ValueError: port number 1 exceeds max of 0
"
Actually with one flowgraph I want to sense the spectrum and with the
other
flowgraph I want to receive normal data. My idea is that when I want to
sence the spectrum I can change some parameters of usrp.source_c and
start
processing sink of one flow graph and when I want to receive normal data
I
can again change some parameters of usrp.source_c and can process the
sink
of corresponding flowgraph. BUT FOR THIS BOTH FLOWGRAPHS SHOULD BE
CONNECTED
TO usrp.source_c AS WE CAN HAVE ONLY ONE usrp.source_c OPEN AT A
TIME???
Is above idea correct and how can I construct such graph???
On Fri, Oct 10, 2008 at 01:15:42AM -0700, kaleem ahmad wrote:
Thanks Eric,
Can you give me a bit more explanation about why it is ‘doomed to fail and
will sooner or later exhaust all memory’. Actually my plan is to run this
graph for ever and I dont have any idea why a graph(especially this one)
will exhibit such behavior and what measure can be taken to avoid this…?
Any clue will be great help for me.
gr.vector_sink_* mallocs memory to store the samples that are sent to
it. You are sending an unbounded number of samples to it.
You have a bounded amount of memory in your system.
"The usrp.source_c block only has one output, so you just connect:
fg.connect(src, fg1)
fg.connect(src, fg2)"
But by doing this my fg2 is working but fg1 is not…It seems as the
connection of fg1 is overwritten by fg2???
By the way I am using gnuradio3.1.1…is there any update in connect
method
in later versions?
By the way I have also tried following:
I am trying to use gdb and I found some other posts by you in which you
recomended that the pid should be printed in the begining and then wait
for
an Enter to be pressed and before pressing Enter open a new terminal and
attach the pid of program_to_be_backtraced with gdb, I did it in the
following way:
#gdb bt pid
after this command gdb execute a sequence of commands
…loading…reading
which ends with the following:
…
…
Loaded symbols for /usr/lib/libglib-2.0.so.0
Reading symbols from /usr/lib/libXinerama.so.1…
—Type to continue, or q to quit—
when I pressed Enter at this point it again run similar loading and
reading…commands and ends at following:
Reading symbols from /usr/lib/libasound.so.2…done.
Loaded symbols for /usr/lib/libasound.so.2
Reading symbols from /usr/local/lib/libgr_audio_alsa.so.0…done.
Loaded symbols for /usr/local/lib/libgr_audio_alsa.so.0
0xffffe410 in __kernel_vsyscall ()
(gdb)
at this point I suppose I can enter bt command to print the
backtrace…BUT the problem is the program which I want to get
the
backtrace of , dont proceed…I mean as soon as it is attached to the
gdb it
stops and never proceed untill I Enter ‘q’ in gdb window and then it
asks me
the following:
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n)
I say yes…and it terminates gdb AND in other terminal where my actual
program is running I receive a message:
fusb::_reap: Interrupted system call…and after this my program
continues.
So my problem is… if my program will never run untill it is attached
with
gdb how can I get backtrace and if I try to print backtrace when the
program
is already crashed then its impossible…So please guide me if I am
doing
something wrong? and suggest me how can I proceed?
The last problem which I posted is solved and now finally I got the
backtrace
of error, which is the following:
#0 0xb710c289 in std::_List_node_base::hook () from
/usr/lib/libstdc++.so.6 #1 0xb54e324a in fusb_ephandle_linux::completed_list_add
(this=0x4f766660,
urb=0x8d5ec88) at /usr/include/c++/4.2.1/bits/stl_list.h:1162 #2 0xb54e364b in fusb_devhandle_linux::_reap (this=0x8d50888,
ok_to_block_p=true) at fusb_linux.cc:268 #3 0xb54e37b2 in fusb_ephandle_linux::reload_read_buffer
(this=0x8d508a0)
at fusb_linux.cc:609 #4 0xb54e38b0 in fusb_ephandle_linux::read (this=0x8d508a0,
buffer=0xb4a640ec, nbytes=14336) at fusb_linux.cc:575 #5 0xb54d69e9 in usrp_basic_rx::read (this=0x8d50600, buf=0xb4a640ec,
len=14336, overrun=0xb4a680fb) at usrp_basic.cc:607 #6 0xb54a2de7 in usrp1_source_base::work (this=0x8d42e58,
noutput_items=3584,
input_items=@0xb4a681e8, output_items=@0xb4a681dc)
at usrp1_source_base.cc:105 #7 0xb60a80fa in gr_sync_block::general_work (this=0x8d42e58,
noutput_items=3584, ninput_items=@0xb4a681f4,
input_items=@0xb4a681e8,
output_items=@0xb4a681dc) at gr_sync_block.cc:64 #8 0xb60a6194 in gr_single_threaded_scheduler::main_loop
(this=0x8d74788)
at gr_single_threaded_scheduler.cc:338 #9 0xb60a76dd in gr_single_threaded_scheduler::run (this=0x8d74788)
at gr_single_threaded_scheduler.cc:86 #10 0xb60a51d4 in gr_scheduler_thread::run_undetached (this=0x8d74a20,
arg=0x0)
at gr_scheduler_thread.cc:98
Can some help me to understand it and let me know where is the error.
Best Regards
Kaleem Ahmad
Eric B. wrote:
fg.connect(src, fg2)"
in later versions?
self.connect(src,fg2)