[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] RuntimeError: udp_sink(1): insufficient connected
Re: [Discuss-gnuradio] RuntimeError: udp_sink(1): insufficient connected output ports
Thu, 31 Aug 2017 20:49:12 -0700
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
I've been having troubles with the master branch lately myself. I've
traced it to having liblog4cpp5 installed or not. If liblog4cpp5 is NOT
installed, GNU Radio seems oddly unstable, especially for OOT modules.
Note that build-gnuradio does NOT install liblog4cpp5.
Try installing liblog4cpp5-dev (sudo apt-get install liblog4cpp5-dev)
and rebuilding GNU Radio.
On 08/31/2017 08:17 PM, Mike Rex wrote:
gnuradio version: 3.7.12git-218-g811bee8c installed from
Dev PC: Xubuntu 16.04 running in VM Workstation (mentioned because
some python bugs are hypervisor effected only)
Problem: I am getting errors when running flow graphs in GRC after
adding variables to the udp_sink_impl.h file.
I've been struggling all week making changes to an existing project
(https://github.com/ghostop14/gr-grnet) that are alternate versions of
TCP/UDP sink/source. I planned on starting with this project, adding
in some missing bits from the gr-blocks UDP sink/source, and then
finally modifying it for our particular application (raw protocol
instead of UDP with IP).
I'm having problems adding variables to
udp_sink_impl.h/udp_source_impl.h without getting errors when running
the flow graph. I may be overlooking something simple, but I'm really
just trying to append the new variable following the usage of other
existing variables. I think there is either something wrong with my
python 2.7 on my xubuntu 16.04 PC, or there needs to be additional
memory allocated somewhere. Typically, when adding a new variable to
udp_sink_impl.h, I'll get the following, where the "NUM needed" varies
from run to run:
Traceback (most recent call last):
File "/home/mike/top_block.py", line 110, in <module>
File "/home/mike/top_block.py", line 99, in main
line 109, in start
line 5681, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: udp_sink(1): insufficient connected output ports
(54929632 needed, 0 connected)
Other times, the flowgraph will start and then crash after the
private constructor finishes and the error will be related to python2
and corrupted size vs prev_size...
*** Error in `/usr/bin/python2': corrupted size vs. prev_size:
Comment out the variable, and then it runs every time. Geez, while
writing this email, I restored the variable to get the corrupted size
error. Pressed Play again and it ran. Sometimes 2/3 tries works, and
other times 2/3 tries gets the python error (I did not notice that
behavior until just now). Added another variable, and then it went up
to like 1 in 6 worked or 1 in 10 worked, and with another variable
added, it doesn't ever work again. So this looks like a memory
allocation/corruption problem that somehow randomly works.
When testing block changes, what is the correct process to ensure
gnuradio sees the newest installed code only? I've been doing:
(current dir is build)
sudo make uninstall && sudo ldconfig && cd .. && rm -rf build
cmake -DCMAKE_BUILD_TYPE="Debug" ../
make -j8 && sudo make install && sudo ldconfig
Is there something I'm missing that completely removes old stuff or
failing to import all the new stuff?
I do have another local repo where I have many more changes and the
payload_size is working (don't know what changed when it suddenly
started working), but further adding variables like 'eof' result in
the error in question. The simplest changes I can make and reproduce
this can be seen here:
I'm changing 4 files:
So either I'm missing something fundamental or my dev setup is bad.
If someone can point out what I'm missing to make this work, I would
greatly appreciate it!
Discuss-gnuradio mailing list